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Foreword 



rd , 



This Technical Report has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is a technical specification of the overall support of Multimedia Broadcast Multicast Service in 
UTRA. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 
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[2] 3GPP TS 22.146: "Multimedia Broadcast/Multicast Service; Stage 1". 

[3] 3GPP TS 22.246: "MBMS User Services; Stage 1". 

[4] 3GPP TS 23.246: "Multimedia Broadcast Multicast Service; Architecture and Functional Description". 

[5] 3GPP TR 25.992: "Multimedia Broadcast Multicast Service (MBMS); UTRAN/GERAN Requirements". 

[6] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network 
(CN) nodes". 

[7] 3GPP TS 33.246: "3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)". 

[8] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[9] 3GPP TS 25.211: "Physical channels and mapping of transport channels onto physical channels (FDD)". 

[10] 3GPP TS 25.221: "Physical channels and mapping of transport channels onto physical channels (TDD) ". 

[II] 3GPP TS 25.304: "User Equipment (UE) procedures in idle mode and procedures for cell reselection in 

connected mode". 

[12] 3GPP TS 25.306: "UE Radio Access capabilities". 

[13] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification". 

[14] 3GPP TS 25.446: 'MBMS Synchronisation Protocol (SYNC)'. 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 
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Figure 3.1 : MBMS Timeline, based on [4]. 

MBMS session start is the point at which the BM-SC is ready to send data. 

MBMS notification informs the UEs about forthcoming and about ongoing MBMS data transfer. 

MBMS Cell Group is a group of multiple cells belonging to one RNS and sharing one PDCP and RLC entity to utilize 
p-t-m transmission of the MBMS Service 

MBMS session stop is the point at which the BM-SC determines that there will be no more data to send for some 
period of time. 

Data transfer is the phase when MBMS data are transferred to the UEs. 

MBMS service availability is the phase between start of service announcement and the end of the last session or stop 
of service announcement. 

MBMS lu data bearer denotes the data bearer estabUshed between SGSN and RNC to transport MBMS data 

MBMS radio bearer denotes the data bearer established between RNC and UE(s) to transport MBMS data 

MBMS RAB denotes both, the MBMS lu data bearer and the MBMS radio beai-er 

MBMS Service Context contains the necessary information for the UTRAN to control the MBMS Service in UTRAN. 

MBMS Activated Services: a set of services made up of those in MBMS multicast mode that the UE has joined as well 
as those in MBMS broadcast mode that the UE is interested in receiving. 

MBMS Selected Services: a subset of the MBMS activated services in MBMS Broadcast mode for which the UE 
applies RRC procedures to inform UTRAN that the service has been selected (by upper layers). 

MBMS lu signalling connection denotes the signalling connection established between the RNC and the CN node to 
serve one MBMS Service Context. 

MBMS Service Announcement: Mechanism to allow users to be informed about the MBMS services available [4] 

Pool area: see definition in ref.[6] 

MBMS Multicast Service Activation: see description in ref.[4] 

Critical Information: MBMS Neighbouring Cell Information, MBMS Radio Bearer Information and MBMS Service 
Information sent on MCCH. 

Non-critical information: MBMS Access Information sent on MCCH. 

MBMS Service Area: The area in which a specific MBMS session is made available. Each transmission and 
retransmission of an MBMS session of an MBMS Bearer Service may be made available to a different MBMS Service 
Area. The MBMS Service Area is described by a Hst of MBMS Service Area IDs, where each MBMS Service Area ID 
represents a group of cells. The definition of an MBMS Service Area ID is independent of an MBMS session, and of an 
MBMS Bearer Service. [4] 

Ll-combining schedule: Indicates when the soft combining is applicable between the specific S-CCPCH of the cell 
and the specific S-CCPCH of the neighbouring cell. 
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MBMS Single Frequency Network: A simulcast transmission technique realised by transmission of identical 
waveforms at the same time via a group of cells covering a geographic area. 

MBSFN mode: In order to achieve higher spectral efficiency synchronized cells operate in MBSFN mode which 
implies that they transmit exactly the same content over an area that is seen as one MBSFN cell by the UE. 

MBSFN cluster: Set of cells operating in MBSFN mode providing only MBMS service in PtM mode and seen as one 
cell by a UE. 

MBMS service transmission schedule: Indicates when the specific MBMS service is expected to be transmitted in the 
cell in specific S-CCPCH. The information is transmitted on MSCH 

S-CCPCH: In case of TDD, the S-CCPCH refers to the CCTrCH carrying EACH. In case of 3.84 Mcps TDD MBSFN 
1MB, the S-CCPCH refers either to S-CCPCH frame type 1 or S-CCPCH frame type 2, or both S-CCPCH frame type 1 
and S-CCPCH frame type 2. 

UE Link denotes the stored information in the RNC on MBMS services joined by the UE in the state other than 
URA_PCH in the course of the UE Linking procedure. 

URA Link denotes the stored information in the RNC on MBMS services joined by a UE in URA_PCH state in the 
course of the URA Linking procedure. 

MBMS Master RNC: role an RNC can take with respect to one or more specific MBSFN cluster(s). MRNC may be 
used for Inter-RNC MBSFN operation whenever dynamic synchronization of radio resources used for MBMS services 
is centrally controlled. There is only one MBMS Master RNC for any MBSFN cluster, which may control one or more 
MBSFN cluster(s). The MRNC has the overall control of the logical resources of the RNSs that are used for MBSFN 
operation within the MBSFN cluster(s). 

Synchronisation Sequence: Each SYNC PDU contains a time stamp which indicates the start time of the 
synchronisation sequence. Each synchronisation sequence has the same duration which is configured in the BM-SC and 
the RNCs operating in inter-RNC synchronisation mode. 

Synchronisation Period: The synchronisation period provides the time reference for the indication of the start time of 
each synchronisation sequence. The time stamp which is provided in each SYNC PDU is a relative value which refers 
to the start time of the synchronisation period. The duration of the synchronisation period is configurable. 

3.2 Symbols 

(void) 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TS 2L905 [1] and the following apply: 

CELL_DCH 

CELL_FACH 

FFS For Further Study 

FLC Frequency Layer Convergence 

1MB Integrated Mobile Broadcast 

LCI Layer Convergence Information 

MBMS Multimedia Broadcast Multicast Service 

MBSFN MBMS over a Single Frequency Network 

MBMS service ID Multimedia Broadcast Multicast Service service Identity 

MBMS Session ID Multimedia Broadcast Multicast Service session identity 

MCCH MBMS point-to-multipoint Control Channel 

MICH MBMS notification Indicator Channel 

MRNC MBMS Mater RNC 

MSCH MBMS point-to-multipoint Scheduling Channel 

MTCH MBMS point-to-multipoint Traffic Channel 

NI Notification Indicator 

PL Preferred Layer 

p-t-p Point-to-Point 
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p-t-m Point-to-Multipoint 

PF Probability Factor 



Background and introduction 



The Introduction of the Multimedia Broadcast Multicast Service in UTRA describes techniques for optimised 
transmission of MBMS bearer service in UTRA such as point-to-multipoint transmission, selective combining and 
transmission mode selection between point-to-multipoint and point-to-point bearer. 

The Stage 1 MBMS service requirements are defined in [2] and MBMS Stage 1 user services are defined in [3]. 
UTRAN (and GERAN) requirements are covered in TR 25.992 [5]. The overall architecture, functional description and 
the reference architecture of MBMS are covered in TS 23.246 [3]. 



5 IVIBIVIS UTRAN and protocol architecture 

5.1 IVIBMS UTRAN architecture principles 
5.1 .1 MBMS Service Context in CRNC 

Each RNC-which is controlling one or several cells within an MBMS Service area maintains an MBMS Service 
Context for each MBMS service. 

1 Each CRNC MBMS Service Context is associated with an MBMS service ID, i.e. TMGI. 

2 The CRNC MBMS Service Context contains a list of PMM connected mode UEs which are present in one or 
several cells of the CRNC and which have activated the MBMS service and/or a list of URAs in which there is 
at least one URA_PCH UE which has activated the MBMS service. The hst includes at least the U-RNTI of the 
UEs in the state other than URA_PCH and/or URA-IDs. 

NOTE: The MBMS Service Context in the CRNC contains no information about RRC Idle mode UEs. 

3 The MBMS Service Context is created in the CRNC either 

if the SGSN informs the RNC that a UE has activated the MBMS Service in a cell controlled by the CRNC 
by the UE Linking procedure. In this case, the CRNC is the SRNC of the UE, 

or if the RNC is notified of an MBMS Session Start, 

- or if the RNC serves as a Drift RNC for a PMM-CONNECTED UE and receives for this UE a UE Link 
from the SRNC containing the MBMS Service Id of the concerned MBMS Service, 

or if the RNC receives a URA Link containing the MBMS Service Id of the concerned MBMS Service. 

4 Each RNC which is informed by the SGSN that a UE has activated one (or several) MBMS Service(s) by the 
UE Linking procedure maintains an MBMS Service Context for each indicated MBMS service, irrespectively 
of the MBMS Service Area. 

5 The MBMS Service Context is released by the CRNC either 

if the MBMS Service Context does not contain any UE/URA information after a UE/URA Unlinking 
procedure from a SGSN and there is no active MBMS Session for the concerned MBMS Service, 

or if the MBMS Service Context does not contain any UE Link/URA Link at the time of a Session Stop 

or if the RNC receives a CN De-Registration for MBMS Service 

6 Associated functionalities: 

6.1 Bearer type selection for MBMS transmissions based on information in the CRNC MBMS Service 
Context. The decision process requires inter-working with Radio Resource Management and with the 
UE's SRNC in the case of p-t-p bearers. 

6.2 MBMS RB control for p-t-m bearers in each cell, based on information in the CRNC MBMS Service 
Context. 
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6.3 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
MBMS Service, has entered a cell. Update of the MBMS Service Context via lur is performed by UE 
Linking. 

6.4 Update of the MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
MBMS Service, has left a cell. Update of the MBMS Service Context via lur is performed by UE Un- 
Linking. 

NOTE: For further details of UE linking via the lur interface see chapter 5.1.6. 

5.1 .2 MBMS Session start and MBMS Session Stop 

At MBMS Session Start and MBMS Session Stop the RNC receives a respective request from the CN. The MBMS 
Session Start Request shall contain the MBMS Service Id, MBMS Bearer Service Type and MBMS Session Attributes 
(MBMS Service Area Information, QoS parameters, ...). The MBMS Session Start Request triggers the RNC to notify 
UEs, which have activated the MBMS Service of the MBMS Session Start. The MBMS Session Stop Request may 
trigger the RNC to notify UEs, which have activated the MBMS Service of the MBMS Session Stop. 

The MBMS Session Start and Session Stop procedures provide the setup and release of the MBMS RAB in the 
following way: 

The MBMS Session Start Request shall contain all information necessary to setup an MBMS RAB. When the RNC 
receives an MBMS Session Start Request, it typically executes MBMS lu data bearer set up and shall inform the 
sending CN node, of the outcome in the MBMS Session Start response message. 

Upon reception of MBMS Session Start Request, if the MBMS Service Context is not yet present in the RNC, the RNC 
shall store the MBMS Service Id. Further the RNC shall memorise the MBMS Bearer Service Type, MBMS Counting 
Information, MBMS Counting Information and MBMS Session Attributes (MBMS Service Area Information, QoS 
parameters, ...) as part of the MBMS Service Context. 

The RNC may choose not to execute the MBMS lu data bearer setup, for a particular MBMS service, when: 

1 . The RNC does not control any cell contained within the MBMS Service Area, or 

2. The RNC controls at least one cell contained within the MBMS Service Area and a list of PMM-Idle Mode 
UEs is included in MBMS Session Start but no RA"s contained within the list are under the control of the 
RNC 

The RNC may not execute the MBMS lu data bearer setup for a given lu interface in case of lu-flex. In those cases the 
CN node shall be informed accordingly. 

In case of lu-flex, the RNC might receive more than one MBMS Session Start Request for an MBMS Service and shall 
not set up more than one MBMS lu bearer for a certain MBMS Service towards a pool area. 

When the RNC receives an MBMS Session Stop Request it shall release the associated MBMS RAB resources. 

The MBMS Session Start and Session Stop procedures serve to establish and release the MBMS lu signalling 
connection. 

5.1.3 MBMS lu bearer 

For each MBMS service, data is transferred via an MBMS RAB between the SGSN and the UE. For each MBMS 
service, data is transferred via one MBMS lu bearer between SGSN and the RNC in the whole MBMS Service area. 
Signalling messages specific for an MBMS Service are transferred via one dedicated MBMS lu signalling connection 
between the RNC and the SGSN. 

1 One MBMS lu bearer is established per MBMS service at MBMS Session Start. 

2 Regarding lu-flex the RNC shall not set up more than one MBMS lu bearer. 

3 Because of the dedicated channels and lur mobility, there is a need to send MBMS data to an RNC which is not 
necessarily part of the MBMS Service area. 

4 The MBMS lu bearer on lu is established per MBMS service and not per UE individually. 

5 Each PMM-CONNECTED mode UE with an activated MBMS service has its UE context bind to the MBMS lu 
bearer. 
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6 There could be several MBMS RBs linked to one MBMS lu bearer (i.e. one MBMS lu bearer on lu maybe 
mapped to multiple DTCH and/or or p-t-m traffic channels over the radio -interface). 

5.1.4 MBMS lub bearer 

The existing FACH transport channel mechanism over lub is to be used in case of p-t-m MBMS transmission. 

5.1 .5 Mapping of MBMS lu bearer to p-t-p and p-t-m connections 

The service specific MBMS RAB on lu may be mapped to p-t-m bearers in order to provide MBMS data via common 
channels. 

1 The MBMS control function in the CRNC may decide to establish a p-t-m connection, if the number of counted 
MBMS users in a cell exceeds a certain operator-defined threshold or if the MBMS Counting Information 
indicates that MBMS Counting procedures are not applicable. 

2 The MBMS control function in the CRNC may decide to establish a p-t-m connection depending on the 
congestion scenario expected for a specific cell (e.g. in hotspot areas where no bearer type switching is needed), 
and/or the MBMS service characteristics (e.g. session duration time) on a per cell basis. 

3 The MBMS control function in the CRNC may, through a configurable parameter enable/disable bearer type 
switching and the associated procedures on a per cell basis. 

4 The MBMS control function in the CRNC establishes an MBMS RB by sending service specific signalling 
messages (e.g. MBMS RB Setup message) to all the UEs in the cell listening MBMS point-to-multipoint 
control channel (MCCH). UEs with activated service(s) may then execute the RB set-up. 

5 MBMS data is transferred on an MBMS point-to-multipoint traffic channel (MTCH) to all the UEs which have 
executed the RB setup. 

6 The MBMS control function in the CRNC releases the MBMS RB (e.g. MBMS RB Release) when the data 

transfer has been finished or it has been interrupted by the CRNC. 

7 p-t-p transmission of MBMS data should use the DTCH as defined for other dedicated services. 

8 p-t-m transmission of MBMS data applies to all RRC states and modes. 



5.1.6 UE Linl<ing/De-linl<ing 



UE Linking denotes the process where a UE, which has joined one or several MBMS services, is linked to one or 
several MBMS service context in the RNC. 

MBMS UE linking procedure in the SRNC is performed in following cases. 

1. When the UE, which has joined an MBMS service, is moved to PMM-CONNECTED and sets up a PS RAB 
This may happen at any point in time during the whole MBMS service availability (i.e. before, during and 
between MBMS sessions). 

2. When the UE joins an MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole MBMS service availability (i.e. before, during and between MBMS 
sessions). 

3. When the UE is moved to PMM-CONNECTED only for MBMS purpose, e.g. to respond to counting/recounting 
indication or respond to p-t-p bearer indication from RNC. This may happen at any point in time during MBMS 
sessions. 

4. When the UE is moved to PMM-CONNECTED and the UE provides MBMS Selected Services Information to 
the RNC. 

Keeping UEs in PMM-CONNECTED only for MBMS between sessions is implementation specific. The UE linking in 
the SRNC for services delivered over MBMS Multicast mode is performed via UE dedicated lu procedures. An entry 
for the UE is added to the related MBMS service context(s) in the SRNC. If an MBMS service context doesn't exist yet 
it needs to be created. 

In cases where a UE is present in a cell under the control of a drift RNC, the UE Linking is performed via lur in the 
following way. 
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1 . When the UE, which has activated one or several MBMS services, is in CELL_DCH state and starts to 
consume radio resources from one or several cells controlled by the DRNC, MBMS UE Linking in the DRNC 
is performed via UE dedicated lur procedures. After that the DRNC shall update the MBMS Service context 
on the request of every radio link setup/release from the SRNC. 

2. When the UE, which has activated one or several MBMS services, is in CELL_FACH state and starts to 
consume radio resources from one cell controlled by the DRNC, MBMS UE Linking in the DRNC is 
performed via UE dedicated lur procedures. After that the DRNC shall update the MBMS Service context in 
the DRNC at every intra-DRNC cell change without the need to receive UE Link from the SRNC. 

3. If the UE is in CELL_DCH and CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the 
DRNC is performed via the MBMS Attach procedure. 

4 If the UE is in CELL_PCH and moves to a cell within the DRNC area for the first time, the MBMS UE 
Linking in the DRNC is performed. The cell the UE moved to is indicated to the DRNC. After that at every 
intra-DRNC cell change the DRNC shall update the MBMS Service context in the DRNC without the need to 
receive UE Link from the SRNC. 

5. If the UE is in CELL_PCH and there is no mobility related signalling activity ongoing for this UE and UE 
Linking is performed in the SRNC for an MBMS Service, MBMS UE Linking in the DRNC is performed via 
the MBMS Attach procedure. 

6 If the UE is in RRC connected mode and UE Linking is performed in the SRNC for an MBMS Service and a 
session of this MBMS Service is ongoing UE Linking in the DRNC needs to be performed immediately. 

At MBMS UE linking in the DRNC the MBMS service context in the DRNC needs to be updated. If an MBMS 
service context does not exist yet then it shall be created and if needed, DRNC can acquire the APN and IP 
Multicast Address from the SRNC for the specific service via Information Exchange procedure. 

UE De-linking denotes the process where a UE, which has joined MBMS service(s), is removed from one or 
several MBMS service contexts in the RNC. 

MBMS UE De-linking procedure in the SRNC is performed in following cases. 

1 . When the UE has left the MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole MBMS service availability (i.e. before, during and between 
MBMS sessions). 

2. When the UE sends new MBMS Selected Services Information to the RNC omitting an MBMS service which 
is identified on the MCCH. 

3. When CN decides to de-link a certain PMM-CONNECTED mode UE due to e.g. error cases. 

MBMS UE De-linking in the SRNC for services in MBMS Multicast mode is performed via UE dedicated lu 
procedure. The entry for the UE is removed from the concerned MBMS service context(s) in the SRNC. 

MBMS UE De-linking procedure in the DRNC is performed via lur in the following way: 

1 . If the UE is in CELL_DCH or CELL_FACH state and stops consuming the radio resources from one or 
several cells controlled by the DRNC, MBMS UE is De-linked from the MBMS Service Context in the DRNC 
via UE dedicated lur procedure. 

2. If the UE is in CELL_DCH or CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE De-linking is performed in the SRNC for an MBMS Service, MBMS UE De-linking in the 
DRNC is performed via the MBMS Detach procedure. 

3 If the UE is in CELL_PCH and leaves for a cell out of the DRNC area the UE is delinked from the MBMS 
Service context in the DRNC via the MBMS Detach procedure. The cell the UE moved out of is indicated to 
the DRNC. 

4. If the UE is in RRC connected mode and UE De-linking is performed in the SRNC for an MBMS Service 
and a session of this MBMS Service is ongoing UE De-linking in the DRNC needs to be performed 
immediately. 
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5.1.7 RNC Registration 



RNC Registration for a certain MBMS Service denotes the process where the CN becomes aware of an RNC hosting 
UEs, which have activated that MBMS Service. 

Due to UE mobihty, a RNC with no MBMS Service Context, can be informed that a PMM-CONNECTED UE, which 
has entered the cell, has activated an MBMS Service by means of the MBMS UE Linking procedure via the lur 
interface. Then the RNC informs the CN that it would like to receive MBMS Session Start Request messages when 
applicable for the concerned MBMS Service by sending MBMS Registration Request message. 

It results in the set-up of a corresponding MBMS distribution tree, but it does not result in the establishment of lu user 
plane, which will be established by the MBMS Session Start procedure. 

1 . Implicit Registration 

RNC Registration for Serving RNCs is performed implicitly, i.e. due to UE linking and MBMS Multicast 
Service Activation. No explicit registration procedure needs to be performed. 

2. Explicit Registration 

RNC Registration for Drift RNCs is performed explicitly if an RNC becomes a Drift RNC for a UE, which 
has activated an MBMS service and has no MBMS Service Context for that MBMS Service. 

RNC Registration for Drift RNCs is performed explicitly if an RNC is no longer the SRNC of any 
connected UE which has activated an MBMS service, but hosts at least a UE which consumes radio 
resources of the RNC via lur. This shall happen only before sessions or between sessions. 

The DRNC will perform a registration towards its default CN node only. 

5.1.8 RNC De-Registration 

RNC De-Registration for a certain MBMS Service denotes the process where the CN becomes aware that an RNC 
registered at a CN node does not host any more PMM-CONNECTED UEs which have activated that MBMS Service. 

• Implicit RNC De-Registration 

RNC De-Registration for Serving RNCs is performed implicitly, i.e due to UE Unlinking and MBMS 
Multicast Service Deactivation. No explicit de-registration procedure needs to be performed. 

• Explicit RNC De-Registration 

RNC De-Registration for Drift RNCs is performed explicitly if a RNC is not acting as a Serving RNC and 
has ceased to act as a Drift RNC for UEs which have activated an MBMS service, it will perform a de- 
registration towards the CN node it was registered to. 

The timing of RNC De-Registration is implementation specific. 

NOTE: When the Drift RNC performes the explicit De-registration, the Implicit registration may still remain and 
in that case lu data bearer should not be removed. 

5.1.9 CN De-Registration 

CN De-Registration denotes the process where the CN informs the RNC that a certain MBMS service is no longer 
available. CN De-Registration should result in releasing of all associated MBMS Service Contexts and resources. 

The CN De-Registration procedure serves to release the MBMS lu signalling connection. 



5.1.10 LIRA Linl<ing/De-linl<ing 



URA Linking denotes the process where a URA, which contains one or more cells in which at least one URA_PCH UE 
has joined the MBMS service or has passed MBMS Selected Service Information about the MBMS service, is linked to 
an MBMS service context in the RNC. An entry for the URA is added to the MBMS service context in the RNC. 

If the UE in URA_PCH state, which has activated one or several MBMS Services, is present within a URA containing 
one or more cells that are controlled by one or more drift RNCs, the URA Linking is performed in the following way. 
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1 . If the UE is in URA_PCH, having activated one or more MBMS services, is the first UE for the particular 
MBMS service to move to a URA which contains one or more cells that are controlled by one or more 
DRNCs, the URA is linked to the MBMS Service context in each applicable DRNC. The URA the UE 
moved to will be indicated. 

2. As long as the SRNC serves UEs in URA_PCH in URAs containing cells controlled by one or more DRNCs, 
the SRNC shall keep the other RNCs informed about every URA in which UEs having activated certain 
MBMS services have to be notified. This is done when the first UE enters the URA, by indicating to the 
other RNCs a list of URAs and the corresponding MBMS Services via MBMS Attach procedure. 

NOTE: Bullet points 1 and 2 above may be merged in a future version of this document. 

At MBMS URA linking in the RNC the MBMS service context in the RNC needs to be updated. If an MBMS service 
context does not exist yet then it shall be created and acquire the APN and IP Multicast Address from the SRNC for the 
specific service via Information Exchange procedure. 

URA De-linking denotes the process where a URA is removed from one or several MBMS service contexts in the RNC. 

1 . If the UE is in URA_PCH and, for the particular MBMS service, is the last UE to leave a URA which 

contains one or more cells controlled by one or more DRNCs the URA is de-linked from the MBMS Service 
context in each applicable DRNC via the MBMS Detach procedure. 

5.1 .1 1 IP Multicast Distribution 

To improve the transport efficiency the IP Multicast may be used for the MBMS payload distribution in the backbone 
network between the GGSN and the RNCs, bypassing the SGSN. 

The GGSN allocates during the session start the Transport Layer Address used for the IP-multicast and the DL TEID 
used for the lu Transport association. The RNCs will receive these parameters from SGSN in the Session Start message 
as part of the MBMS session attributes. 

The RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start Response to the 
SGSN. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in order to join 
the bearer service multicast distribution. If one or more downstream RNC nodes doesn"t accept IP Multicast 
distribution, the SGSN will establish an MBMS RAB which the IP multicast distribution is not applied, to related 
RNCs. 

The MBMS payload is forwarded by the GGSN towards the IP Multicast address. The RNCs joined to that IP Multicast 
address will receive the user data packets (SYNC PDU) together with the synchronisation-related information in header 
part of SYNC PDU. The information in header part of SYNC PDU is delivered to allow the softcombining and MBSFN 
transmission across the RNCs. The details of inter-RNC synchronization are described in section 7. IB. 

In case the header compression is used in MBMS PtM mode for an MBMS stream the compression is done in BM-SC. 
The usage of header compression is configured in advance in the BM-SC and the RNC is receiving the information 
during the MBMS Session start as part of the session attributes. In case header compression is configured, the MBMS 
user data packets forwarded from BM-SC to RNCs via GGSN will contain in addition to the synchronisation-related 
information and PDCP protocol information, the full IP header of the payload and the payload with compressed header. 
The RNC using MBMS PtP mode in a cell may process the UE dedicated RoHC for the full IP header of the payload 
and replace the compressed header of PtM mode with it. 



5.2 MBMS Uu Principles 



5.2.1 MBMS Service States in UE 

The MBMS bearer service has following service states in the UE: 

1. Not active, UE has not joined any MBMS multicast service or not activated the broadcast mode of the MBMS 

2. Not active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the 
MBMS, but MBMS SYSTEM INFORMATION is not broadcasted on BCCH. 
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3. Active, UE has joined at least one MBMS multicast service and/or activated the broadcast mode of the MBMS, 
but any of the services that UE has joined (interested in broadcast mode) is not being transmitted. UE monitors 
MICH to find modifications in the MCCH as defined in 5.1.6 

4. Active; at least one MBMS service appearing in the list of MBMS Activated Services, is received on p-t-m 

UE is receiving MBMS transmission on MTCH 

UE is using DRX based on scheduling information informing that coming MTCH transmission is not 
in the interest of the UE. 

5. Active; at least one MBMS service is received on p-t-p 

6. Active; at least one MBMS service is received on p-t-p and at least one MBMS service is received on p-t-m. 
(only valid if UE has capability to support this combination) 

When MBMS transmission is started in cell the UE moves from state 3 to either state 4 or state 5 (6), depending on 
p-t-p transmission mode and after MBMS transmission ends in the cell, the UE moves from state 4 or state 5 (6) to state 
3. 

5.2.2 One PDCP and RLC entity shared among multiple cells within one 
RNS 

For each MBMS service, a group of multiple cells belonging to one RNS shares one PDCP entity and RLC entity over 
p-t-m transmission. The group of multiple cells is called 'MBMS Cell Group'. 

1 . There are one or more MBMS Cell Groups per RNS. The MBMS Cell Groups are managed by the CRNC. 

2. There are one or more cells pertaining to the same RNS for one MBMS Cell Group. 

3. The MBMS Cell Group identity is used to uniquely identify a group of multiple cells, which for each MBMS 
service share the same PDCP entity and RLC entity within an RNS. 

In case the MBMS combining methods are used across multiple RNSs for an MBMS service, the RNSs belong to the 
same IP Multicast group used for the MBMS user data distribution from the GGSN to CRNCs. One common PDCP 
entity for header compression is used for MBMS P-t-M transmission among the RNSs being part of the IP Multicast 
group. 

The RLC entity for p-t-m transmission is shared by a group of multiple cells belonging to one RNS. The RLC entities, 
within the RNSs shall be synchronized to each other in way that they, process the user data in the same manner with the 
help of information delivered by the SYNC-protocol to RNS. 

5.2.3 MCCH Information Scheduling 

The MCCH information will be transmitted based on a fixed schedule. This schedule will identify the TTI containing 
the beginning of the MCCH information. The transmission of this information may take a variable number of TTIs and 
the UTRAN should transmit MCCH information in consecutive TTIs. The UE will keep receiving the S-CCPCH until: 

It receives all of the MCCH information, or 

It receives a TTI that does not include any MCCH data, or 

The information contents indicate that further reception is not required (e.g. no modification to the desired 
service information). 

Based on this behaviour, the UTRAN may repeat the MCCH information following a scheduled transmission in order to 
improve reliability. The MCCH schedule will be common for all services. 

The entire MCCH information will be transmitted periodically based on a "repetition period". The "modification 
period" will be defined as an integer multiple of the repetition period. The MBMS ACCESS INFORMATION may be 
transmitted periodically based on an "access info period". This period will be an integer divider of the "repetition 
period". 
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MCCH information is split into critical and non-critical information. The critical information is made up of the MB MS 
NEIGHBOURING CELL INFORMATION, MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION. The non-critical information corresponds to the MBMS ACCESS INFORMATION. Changes to 
critical information will only be applied at the first MCCH transmission of a modification period and in the beginning 
of each modification period UTRAN transmits the MBMS CHANGE INFORMATION including MBMS services ids 
whose MCCH information is modified at that modification period. MBMS CHANGE INFORMATION is repeated at 
least once in each repetition period of that modification period. Changes to non-critical information could take place at 
any time. 

The Figure 5.2.3 below illustrates the schedule with which the MBMS SERVICE INFORMATION and RADIO 
BEARER INFORMATION would be transmitted. Different colours indicate potentially different MCCH content. 
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Figure 5.2.3: MCCH Information Schedule 

5.2.4 MBMS Notification 

The MBMS notification mechanism is used to inform UEs of an upcoming change in critical MCCH information. 
Notifications are based on service groups. The mapping between service IDs and service groups is specified in [II]. 

The MBMS notification indicators will be sent on an MBMS specific PICH, called the MICH. A single MICH frame 
will be able to carry indications for every service-group. 

Critical MCCH information can only be changed at the beginning of a modification period as described in Section 5.2.3. 
The MBMS notification indicator corresponding to the service group of every affected service shall be set continuously 
during the entire modification period preceding the first change in MCCH information related to a given service. 
Subsequent changes in the MCCH information in the next modification period related to the same service can be 
signalled on the MCCH. 

UEs which are not receiving any MBMS service on MTCH or p-t-p channel are free to read the MBMS notification at 
any time; however the modification interval shall be long enough so that UEs are able to reUably detect it even if they 
only receive the MICH during their regular Release '99 paging occasions. 

Upon detecting the MBMS notification indication for a service group, UEs with an activated service service 
corresponding to this group shall start reading the MCCH at the beginning of the next modification period. The UE 
shall read at least MBMS CHANGE INFORMATION. 

The Figure 5.2.4 below illustrates the timing relation between the setting of the MICH and the first MCCH critical 
information change. The green colour for the MICH indicates when the NI is set for the service. For the MCCH, 
different colours indicate MCCH content related to the notification of different services. 

UEs, which are receiving MBMS service(s) on MTCH in idle mode or URA_PCH, CELL_PCH, or CELL_FACH state 
shall read the MCCH at the beginning of the each modification period to receive the MBMS CHANGE 
INFORMATION, which will indicate MBMS service Ids and optionally MBMS Session ID whose MCCH information 
is modified at that modification period. If MBMS service Id and optionally MBMS Session ID, which UE has activated, 
is indicated in MBMS CHANGE INFORMATION the UE shall read the rest of the MCCH information. 
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Figure 5.2.4: Illustration of MICH timing relative to Modification period 



5.2.5 MBMS Counting 



MBMS Counting is used to determine the optimum transmission mechanism for a given service. 

1 . The need for counting is indicated in the notification, and achieved by requesting UEs, belonging to the same 
MBMS service group, to respond to counting by sending MBMS COUNTING RESPONSE signalling flow to 
CRNC. 

a. For UEs in idle mode the counting response refers to the RRC connection establishment procedure. 

b. For UEs in URA_PCH, or CELL_PCH state the counting response refers to cell update procedure 
c For UEs in CELL_FACH state the counting response refers to signalling on CCCH or DCCH. 

2. The exact number of UEs that need to respond to counting is an RRM issue. 



Since it is desirable in a specific cell, to avoid bringing a large number of UEs for counting purposes to RRC 
connected mode at the same time (RACH load, etc), RRM may control the load due to the RRC connection 
establishment requests, by setting an access "probability factor". For UEs in PMM connected mode the 
UTRAN may set different "probability factor" than for UEs in idle mode. 

Following counting, the number of subscribers that need to be maintained in RRC connected mode or for 
which the RNC releases their connection, is also an RRM issue. In Broadcast Mode, the RNC may also decide 
to reject the RRC connection establishment and indicate during this reject that counting has been completed. 



5. For a given MBMS service, the counting indication in the notification may be switched on and off, on per-cell 

basis. 

6. The RNC may use notification to indicate counting during an ongoing MBMS session (term used is re- 
counting). 

7. The RNC receives via lu from CN information (MBMS service ID) about UEs who are in RRC Connected 
mode, and have joined the MBMS service. This information may be used for counting purposes. 

The MBMS counting function includes a mechanism by which the UTRAN can prompt UEs with a given activated 
service to become RRC connected. This procedure is only applicable for UEs in idle mode and relies on the MBMS 
ACCESS INFORMATION transmitted on the MCCH. The probability factor indicates the probabiUty with which UEs 
need to attempt an RRC connection procedure. 

In order to trigger counting for a given service, the UTRAN may use the regular MBMS notification mechanism 
outlined in section 5.2.4 to force UEs with that service activated to read the MCCH information. 

Once a UE detects that the counting procedure is on-going for the specific service it wants to receive, it will attempt to 
respond to the counting based on the probability factor included in the MCCH. If the response to counting is for a 
service identified in the list of MBMS Selected Services, the UE should provide the MBMS Service ID in the response. 
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Also, the UE will keep receiving the MBMS ACCESS INFORMATION at every access info period until the UE 
successfully responds to the counting or counting is no longer required. Whenever it receives new MBMS ACCESS 
INFORMATION the UE will update its probability factor with the new value. 

The Figure 5.2.5 below illustrates this mechanism. The green colour for the MICH indicates when the NI is set for the 
service. The green colour for the MBMS ACCESS INFORMATION indicates that the counting procedure is on-going 
and that UEs need to establish an RRC connection based on the included probability factor (PF). For the critical MCCH 
info, different colours indicate potentially different content. 
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Figure 5.2.5: Illustration of Access Info period during IVIBMS counting 

For every UE brought to RRC connected state for the purpose of counting, UTRAN wiU initiate the PMM Connection 
establishment procedure and will obtain from CN the set of MBMS services these users have joined. 

Counting for on-going services (re-counting) will rely on the same scheduling of the MCCH information. 

5.2.6 MBMS Radio Bearer Release in tine UE 

The UE releases the MBMS RB by using one of the following mechanisms: 

- Exphcit MBMS RB Release 

- Implicit MBMS RB Release 

The Explicit MBMS RB Release mechanism allows UTRAN to explicitly indicate to MBMS UEs that an MBMS Radio 
Bearer should be released. For p-t-m transmissions the Explicit MBMS RB Release indication is contained within the 
MBMS SERVICE INFORMATION signalling flow. For p-t-p transmission the release of MBMS radio beai-ers is 
completed in the same way as for a non-MBMS radio bearer. If the Explicit MBMS RB Release indication is received, 
the UE releases the MBMS RB. 

The Implicit MBMS RB Release mechanism applies only to p-t-m transmission and enables a UE to release the MBMS 
Radio Bearer without receiving the Explicit MBMS RB Release. The UE identifies Implicit MBMS RB release if it 
detects that the RB is not present in the MBMS SERVICE INFORMATION signalUng flow. 
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5.2.7 MBMS Session Repetition 



In the case that the BM-SC repeats MBMS sessions (send multiple time identical content), the MBMS service Id and 
MBMS session Id is used to identify specific MBMS service and session. The validity of the session Id is handled on 
the MBMS application layer between the BM-SC and the UE. If UTRAN receives the MBMS session ID in session 
start, the UTRAN should: 

■ include MBMS session Id in critical and non critical information send on MCCH 
Note: The non-critical information may contain index referring to critical information, 
avoiding repetition of MBMS service and session Id in non-critical information. 

If the UE has already received correctly the data of the MBMS session, which is being indicated on MCCH, the UE 
may: 

ignore PLC by not applying the Layer Convergence Information 

ignore counting procedure in Idle, URA_PCH, CELL_PCH, and CELL_FACH state 

ignore p-t-m MBMS RB setup signalled on MCCH 

ignore p-t-p MBMS RB indication signalled on MCCH 

reject the p-t-p RB setup for MBMS service, signalled on DCCH 

In the case that UTRAN receives reject from the UE to the p-t-p RB setup for MBMS service on DCCH, the UTRAN 
should not try to re-establish p-t-p RB setup for that MBMS service and session. 

In the case that the UE has accepted the p-t-p RB for repeated MBMS session the UE shall receive the complete 
session. 

5.2.8 MBMS Service Prioritisation 

The CN may assign the Allocation and Retention Priority for the MBMS bearer service. The Allocation and Retention 
Priority allows for prioritisation between MBMS bearer services and between MBMS bearer services and non MBMS 
bearer services in the UTRAN. 

The UE may assign internally different priorities for different MBMS services to prioritise MBMS and non MBMS 
service reception. In case that UE has no capability to receive simultaneously, the dedicated non MBMS service and the 
MBMS service and the MBMS service has priority over the non MBMS service the UE may: 

■ initialise signalling with CN on NAS layer to stop reception of dedicated non MBMS service 

If the UE has no capacity on receiving all MBMS services, which it has activated and which are transmitted 
simultaneously on p-t-m RBs, the UE may 

■ stop autonomously ongoing reception of lower priority MBMS service 

■ act on MCCH message assigned to the highest priority MBMS service 

■ start autonomously the reception p-t-m RB of the highest priority MBMS service 

If the reception p-t-p RB of the lower priority MBMS service is blocking the reception of p-t-m RB of the higher 
priority MBMS service the UE may: 

If p-t-p RB is being established 

■ reject the setup of p-t-p MBMS RB 

If the UTRAN receives reject message UTRAN should not try to re-establish p-t-p RB setup for that MBMS service 
and session. 

If p-t-p RB is already existing 

■ request the release of p-t-p MBMS RB from the UTRAN or only indicate frequency of 
higher priority MBMS service 
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If the UTRAN receives release request message UTRAN may release the p-t-p MBMS RB. 



5.3 



Protocol structure 



5.3.1 MBMS User Plane Protocol Stack Architecture 
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Figure 5.3.1-1 : Protocol Stack for MTCH 

Figure 5.3.1-1 illustrates the protocol termination for MTCH in MBMS, which is used in p-t-m transmission. 

If configured by CRNC the PDCP sub-layer performs header compression/decompression for the MBMS traffic. 

The PDCP sub-layer may operate with the RFC 3095 header compression protocol. In that case, header compression 
should be performed under RFC 3095 U-mode. 

In the UTRAN, for p-t-m transmission, there is one PDCP entity for each MBMS service for each MBMS Cell Group 
that provides the service (an MBMS Cell Group may contain one or more than one cell). 

In the UTRAN, for p-t-m transmission, there is one RLC entity for each MBMS service in each cell or cell group in 
case of utilization of selective combining or maximum ratio combining in TDD, and one MAC entity for each cell. 

In the UE side, there is one PDCP and RLC entity for each MBMS service in each UE. In each UE there is one MAC 
entity per received cell when UE is performing the selective combining between these cells. 

In case of p-t-p transmission, DTCH is used for MBMS transmission and the protocol termination for DTCH mapped 
on DCH and RACH/FACH are presented in [8]. 
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Figure 5.3.1-2: Protocol Stack for MTCH (P-T-M) in case of IP multicast distribution 

Figure 5.3.1-2 illustrates the protocol termination for MTCH in MBMS, which is used in p-t-m transmission in case of 
IP Multicast distribution. 
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Based on the configuration in BM-SC the PDCP sub-layer may perform header compression/decompression for the 
MBMS traffic. 

The PDCP sub-layer may operate with the RFC 3095 header compression protocol. In that case, header compression 
should be performed under RFC 3095 U-mode. 

In the UTRAN, for p-t-m transmission, there is one PDCP entity for each MBMS service for each MBMS IP Multicast 
Group that provides the service (an MBMS IP Multicast Group may contain one or more than one RNC, see section 

5.2.2). 

For p-t-m transmission there is one RLC entity for each MBMS service in each cell or in a group of multiple cells 
belonging to one RNS. The RLC entities, in the RNSs synchronized to each other, shall process the user data similar 
manner with the help of information delivered by the SYNC -protocol to RNS. There is one MAC entity for each cell. 

In the UE side, there is one PDCP and RLC entity for each MBMS service in each UE. In each UE there is one MAC 
entity per received cell when UE is performing the selective combining between these cells. 

In case of p-t-p transmission, DTCH is used for MBMS transmission and the protocol termination for DTCH mapped 
on DCH and RACH/FACH are presented in [8]. 

5.3.2 MBMS Control Plane Protocol Stack Architecture 
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Figure 5.3.2-1 : Protocol Stack for MCCH and MSCH 



Figure 5.3.2-1 illustrates the protocol termination for MCCH and MSCH in MBMS, which are MBMS p-t-m control 
channels. 

MBMS functionalities are included in MAC and RRC. 

In case of p-t-p transmission, DCCH is used for MBMS and the protocol termination for DCCH mapped on DCH and 
EACH are presented in [8]. 
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Figure 5.3.2-2: Protocol Stack for MCCH 



MBMS Master 
RNC 



In case MRNC is used, figure 5.3.2-2 illustrates the protocol termination for MCCH in MBMS, which is MBMS p-t-m 
control channel. 
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MBSFN MCCH Information Control function is split between MRNC and CRNC. The MRNC controls the logical 
resources of the RNSs that are used for MBSFN operation within the MBSFN cluster(s). The MRNC informs the 
CRNC of the MCCH configuration (using transfer of MCCH Information Control messages) and schedule information 
to be used (included in RNSAP). The CRNC performs the MCCH configuration and sends the MCCH information 
accordingly. 



5.4 



MAC architecture 



5.4.1 UTRAN MAC Architecture to support IVIBIVIS 
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Figure 5.4.1 : UTRAN MAC architecture 

To support MBMS user and control plane transmission, a multicast functionality is added in the MAC c/sh, entitled 
"MAC m", to take care of scheduling of MBMS related transport channels as presented in Figure 5.4.1. In addition, 
three logical channels are considered for p-t-m transmission of MBMS; MCCH, MSCH and MTCH. These logical 
channels are mapped on FACH. In case of p-t-p transmission DTCH and DCCH are used. 

5.4.2 iVIAC-c/sin/m arcinitecture: UTRAN side 

Figure 5.4.2 illustrates the MAC-m additions to the MAC -c/sh architecture in the UTRAN side, needed to transmit 
MBMS data over a common transport channel (FACH). 

MAC-c/sh/m is located in the controlling RNC. The following functionalities are covered: 

Scheduling / Buffering / Priority Handling: This function manages common transport resources between 
MBMS and non-MBMS data flow(s) according to their priority and delay requirements set by higher 
layers. 

TCTF MUX: This function handles insertion of the TCTF field in the MAC header and also the respective 
mapping between logical channels (i.e. MTCH and MCCH) and transport channels. The TCTF field 
indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Addition of MBMS-ID: For p-t-m type of logical channels, the MBMS-ID field in the MAC header is 
used to distinguish between MBMS services. 

TFC selection: Transport format combination selection is done for a common transport channel (FACH) 
mapped to MTCH, MSCH and MCCH. In the case of MBMS soft combining (excluding TrCH combining 
in TDD), the combinable S-CCPCHs shall have the same TFC during the TTIs in which LI combining is 
used. 
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There is one MAC-c/sh/m entity in the UTRAN for each cell. 
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Figure 5.4.2: UTRAN side IVIAC-m archiitecture additions to IVIAC-c/sli 



5.4.3 MAC-c/sh/m architecture: UE side 

Figure 5.4.3 illustrates the MAC-m additions to the MAC-c/sh architecture in the UE side, needed to receive MBMS 
data over a transport channel (FACH). 

The following functionalities are covered; 

TCTF DEMUX: This function handles detection and deletion of the TCTF field in the MAC header, and 
also the respective mapping between logical channels (i.e. MTCH and MCCH) and transport channels. 
The TCTF field indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

Reading of MBMS-ID: The MBMS-ID identifies data to a specific MBMS service. 

There is one MAC-m entity in the UE or in case of selective combining one MAC-m entity for each selectively 
combined cell in the UE. 
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Figure 5.4.3: UE side IVIAC-m additions to IVIAC-c/sh 
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6 MBMS Channel Structure 

There exists two transmission modes to provide the MBMS service: 
Point-to-point transmission (p-t-p) 
Point-to-muhipoint transmission (p-t-m) 

6.1 Point-to-Point Transmission 

Point-to-point transmission is used to transfer MBMS specific control/user plane information as well as dedicated 
control/user plane information between the network and one UE in RRC Connected Mode. It is used only for the 
multicast mode of MBMS and for services identified in the list of MBMS Selected Services. 

For a UE in CELL_FACH and Cell_DCH, DCCH or DTCH is used, allowing all existing mappings to transport 
channels. 

A detailed description of channels used for point-to-point transmission is given in [8]. 

6.2 Point-to-multipoint Transmission 

Point-to-multipoint transmission is used to transfer MBMS specific control/user plane information between the network 
and several UEs in RRC Connected or Idle Mode. It is used for broadcast or multicast mode of MBMS. 

6.2.1 Logical Channels 

6.2.1 .1 MBMS point-to-multipoint Control Channel (MCCH) 

This logical channel is used for a p-t-m downlink transmission of control plane information between network and UEs 
in RRC Connected or Idle Mode. The control plane information on MCCH is MBMS specific and is sent to UEs in a 
cell with an activated (joined) MBMS service. MCCH can be sent in S-CCPCH carrying the DCCH of the UEs in 
CELL_FACH state, or in standalone S-CCPCH, or in same S-CCPCH with MTCH. For 3.84 Mcps TDD MBSFN 1MB, 
MCCH is sent in a standalone S-CCPCH frame type 1 only. 

The MCCH is always mapped to one specific EACH in the S-CCPCH as indicated on the BCCH. If MCCH is the only 
logical channel mapped in to the EACH, the absence of the TCTE field is explicitly signalled otherwise the TCTE field 
is used in MAC header to identify MCCH logical channel type. In case of soft combining, the MCCH is mapped to a 
different S-CCPCH (CCTrCH in TDD) than MTCH. 

Reception of paging has priority over reception of MCCH for Idle mode and URA/CELL_PCH UEs. 

6.2.1 .2 MBMS point-to-multipoint Traffic Channel (MTCH) 

This logical channel is used for a p-t-m downlink transmission of user plane information between network and UEs in 
RRC Connected or Idle Mode. The user plane information on MTCH is MBMS Service specific and is sent to UEs in a 
cell with an activated MBMS service. 

The MTCH is always mapped to one specific EACH in the S-CCPCH, or in the S-CCPCH frame type 2 in case of 3.84 
Mcps TDD MBSEN 1MB, as indicated on the MCCH. The TCTE field is always used in MAC header to identify 
MTCH logical channel type. 

6.2.1 .3 MBMS point-to-multipoint Scheduling Channel (MSCH) 

This logical channel is used for a p-t-m downlink transmission of MBMS service transmission schedule between 
network and UEs in RRC Connected or Idle Mode. The control plane information on MSCH is MBMS service and S- 
CCPCH specific and is sent to UEs in a cell receiving MTCH. One MSCH is sent in each S-CCPCH carrying the 
MTCH. 



£75/ 



3GPP TS 25.346 version 9.1.0 Release 9 



26 



ETSI TS 125 346 V9.1.0 (2010-04) 



The MSCH is always mapped to one specific FACH in the S-CCPCH as indicated on the MCCH. Due to different error 
requirements the MSCH is mapped to a different FACH than MTCH. If MSCH is the only logical channel mapped in to 
the FACH, the absence of the TCTF field is explicitly signalled otherwise the TCTF field is used in MAC header to 
identify MSCH logical channel type. 

6.2.2 Transport Channel 

FACH is used as a transport channel for MTCH, MSCH and MCCH. 

6.2.3 Physical Channel 

SCCPCH is used as a physical channel for FACH carrying MTCH or MCCH or MSCH. 

6.2.4 Mapping between channels 

Only in downlink, the following connections between logical channels and transport channels exist: 

- MCCH can be mapped to FACH 

- MTCH can be mapped to FACH 

- MSCH can be mapped to FACH 

The mappings as seen from the UE and UTRAN sides are shown in Figure 6.2.4-1 and Figure 6.2.4-2 respectively. 
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SAP SAP SAP 




MAC SAPs 



Transport 
FACH Channel 

Figure 6.2.4-1 : Logical channels mapped onto transport channel, seen from the UE side 
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Figure 6.2.4-2: Logical channels mapped onto transport channel, seen from the UTRAN side 
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6.2.5 Data Flows through Layer 2 

6.2.5.1 Data flow for MCCH mapped to FACH 

For MCCH, the RLC mode to be employed is UM-RLC, with required enhancements to support out of sequence SDU 
dehvery. A MAC header is used for logical channel type identification. 

6.2.5.2 Data flow for MTCH mapped to FACH 

For MTCH, the RLC mode to be employed is UM-RLC, with required enhancements to support selective combining. 
Quick repeat may be used in RLC-UM. A MAC header is used for logical channel type identification and MBMS 
service identification. For MBMS in case of inter-RNC MBSFN and soft combining, MAC PDUs to be transmitted in 
one TTI shall be ordered according to MBMS-ID when multiple MTCHs are multiplexed onto one FACH. 

6.2.5.3 Data flow for MSCH mapped to FACH 

For MSCH, the RLC mode to be employed is UM-RLC. A MAC header is used for logical channel type identification. 

6.3. MBMS Notification Indicator Channel 

MBMS notification utilizes a new MBMS specific PICH called the MBMS Notification Indicator Channel (MICH) in 
each cell. Its coding is defined in [9] (FDD) and [10] (TDD). 



7 IVIBIVIS Reception and UE Capability 

7.1 Selective and Soft Combining for MBMS P-T-M 
transmission 

The selective combining for MBMS p-t-m transmission is supported by RLC PDU numbering. Therefore, the selective 
combining in the UE is possible from cells providing similar MBMS RB bit rate, provided that the de-synchronization 
between MBMS p-t-m transmission streams does not exceed the RLC re-ordering capability of the UE. Thus, there exist 
one RLC entity in the UE side. 

To support selective combining it is decided to: 

Introduce re-ordering as a configurable feature of RLC-UM, within the RLC specification. 

Use the same mechanism as what is specified for MAC-hs (single Tl timer). 

For selective combining there exist one RLC entity per MBMS service utilizing p-t-m transmission in the cell group of 
the CRNC. All cells in the cell group are under the same CRNC, i.e. lur support is not considered. 

For soft combining to be possible, the relative delay between the radio links to be combined, when they are received by 
the UE, must be no more than (1 TTI)h-(1 slot). 

The UE capability requirements to support selective and soft combining are defined in chapter 7.2. In case de- 
synchronization occurs between MBMS transmissions in neighbouring cells belonging to an MBMS cell group the 
CRNC may perform re-synchronization actions enabling UEs to perform the selective combining between these cells. 

For TDD, selection combining and soft combining can be used when Node-Bs are synchronised. For FDD soft 
combining can be used when Node-Bs are synchronized inside UE"s soft combining reception window, and the data 
fields of the soft combined S-CCPCHs are identical during soft combining moments. 

When selective or soft combining is available between cells the UTRAN should send MBMS NEIGHBOURING CELL 
INFORMATION containing the MTCH configuration of the neighbouring cells, available for selective or soft 
combining. When partial soft combining is applied the MBMS NEIGHBOURING CELL INFORMATION contains the 
LI -combining schedule, which indicates the time moments when the UE may soft combine the S-CCPCH transmitted in 
neighbouring cells with the S-CCPCH transmitted in the serving cell. With MBMS NEIGHBOURING CELL 
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INFORMATION the UE is able to receive MTCH transmission from neighbouring cell without reception of the MCCH 
of that cell. 

The UE determines the neighbouring cell suitable for selective or soft combining based on threshold (e.g. measured 
CPICH Ec/No) and the presence of MBMS NEIGHBOURING CELL INFORMATION of that neighbour cell. 

The possibility of performing selective or soft combining should be signalled to the UE. 

7.1 .bis Simulcast Combining (TDD only) 

In contrast to FDD, downlink macro diversity has not been a characteristic of TDD during release '99/4/5. As such 
TDD receivers are not typically designed to facilitate the simultaneous reception of multiple radio links and the 
incorporation of such a requirement for MBMS in TDD would have non-trivial impacts on the receiver design. 

Much of the receiver complexity increase associated with the combining of multiple radio links in the UE can however 
be avoided in TDD by combining macro-diversity with timeslot re-use. This also allows for the throughput gains from 
timeslot re-use to be combined with further gains from macro diversity. 

In such a scheme, the transmissions of the same information from the multiple participating cells are arranged such that 
they arrive at the UE on substantially different timeslots, thereby removing the requirement at the UE to detect multiple 
cells in the same timeslot. 

As such, cells are partitioned into transmission "groups" or "sets". Each transmission set is allocated a timeslot (or set 
of timeslots) for MBMS transmission. The assigned slots are typically exclusively used by that MBMS set; sets do not 
transmit when another set is active. The UE attempts to receive information from each set and to combine them either 
at the physical layer or RLC layer in order to enhance reception reliability. 

Figure 7.1. bis shows such a scheme applied to a tri-sectored deployment model. 3 timeslots (t|, tj and t^) are allocated to 
each sector for the purposes of MBMS transmission. Each sector is assigned to a particular "MBMS transmission set", 
set 1, 2 or 3. 

An MBMS data unit or transport block is encoded over several radio frames (eg: 80ms TTI). The physical channel bits 
that result are effectively transmitted three times; once by MBMS set 1 in timeslot ti, once by MBMS set 2 in timeslot 
t2, and once by MBMS set 3 in timeslot t^. 
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Figure 7.1. bis: Example of non-time-coincident macro diversity transmission 

A given UE may be configured to listen to the separate transmissions of the MBMS physical channels (one from each 
set) which, over the course of the TTI, correspond to the MBMS transport block(s). The signals from each MBMS set 
are largely non-time -coincident and do not require the use of an extensively modified receiver architecture -a receiver 
architecture resembling that of a normal "single-radio-link" TDD receiver may be used. 

The received transport blocks may be provided to the RLC layer for selective combining, or soft information may be 
buffered and combined across MBMS sets during the course of the TTI via physical layer soft combining . 

The UTRAN shall signal to the UE on the MCCH which services may be soft combined (and in which cells). The cell 
group for soft combining may be different than the cell group for selective combining. The UE may assume that 
transmissions of a given service that may soft combined take place in the same frame. 

7.1 .ter Chip Combining (1 .28Mcps TDD) 

Chip Combining is a technique that bears some relation to Space Code Transmit Diversity (SCTD) in existing releases 
except that the combining is performed between cells with different scrambling codes instead of between transmit 
antennas of the same cell with the same scrambling code. 

Chip Combining has been proposed as another form of combining method for p-t-m transmissions for 1 .28Mcps TDD 
mode. All involved cells still keep their own configuration of scrambling code (i.e. different cells participating in the p- 
t-m transmission have different scrambling codes on the MBMS timeslots). As for SEN transmission, in Chip 
Combining mode, all Node Bs involved are closely time synchronized, which is an inherent characteristic of TDD 

systems. 



ETSI 



3GPP TS 25.346 version 9.1 .0 Release 9 30 ETSI TS 1 25 346 V9.1 .0 (201 0-04) 

The UE interested in one p-t-m MBMS service gets the active configuration, such as the midamble codes and the 
scrambling codes used in the current cell and in the involved neighbouring cells from BCCH and/or MCCH. The UE 
must monitor the signal strengths of the involved cells and must select a number of cells to combine. In an active p-t-m 
timeslot, the UE performs channel estimation of each cell to be combined and gets the system matrixes of each involved 
cell respectively, and then, one compound system matrix can be formed by combining the system matrix of these 
involved cells. After that, the UE uses joint detection algorithm to recover the MBMS data with the compound system 
matrix. 

Chip Combining brings no change and requirement to network equipment. However, in order to approach the 
performance offered by SEN, a relatively large number of cells must be detected and efficiently combined by the UE. 
Alternatively, chip combining could be used for small service areas (only a small number of cells participate in a 
simulcast transmission). In this case the number of cells which must be combined by the UE can be reduced and the 
performance loss compared to SEN is then lowered. 

A UE should have a minimum capability to detect and combine a certain number of cells so that performance of the 
MBMS p-t-m (and hence coverage of the MBMS service) can be guaranteed. The complexity of the UE and the 
performance of the chip combining method would have some bearing on the choice of this minimum number of cells 
that must be combined by the UE. 

7.1 A MBMS over a Single Frequency Network (MBSFN) 

Another form of combining is possible for p-t-m transmissions and is realised via utilisation of the same scrambling 
code at a given moment in time by a group of cells covering a geographic area and is applicable for EDD and for TDD. 
This form of combining is referred to as MBMS over a Single Erequency Network (MBSEN). Signals from multiple 
cells may be combined by the UE in the same manner as used for multipath signal components from a single cell. 

The UE reception of MBMS services provided in MBSEN mode shall not affect the UE behaviour on the unicast 
carrier. Especially the UE mobility on the unicast carrier is not affected by the reception of MBMS services provided on 
a cell operating in MBSEN mode and can imply that the reception of the MBMS service on the cell operating in 
MBSEN mode is impossible due to the limited support of combination of frequency bands for MBMS SEN reception 
and unicast reception. 

MBSFN requires all Node Bs involved in the simulcast transmission to be closely time synchronised and exactly the 
same content is delivered to each of the involved Node Bs. All involved Node Bs are assumed to share the same CRNC 
(the MBSEN area is limited to the area controlled by a single RNC). 

Eor TDD, some or all timeslots may utilise an MBSEN mode of transmission. Such timeslots are configured by the 
RNC to use the same scrambling codes across participating Node-Bs. Any non-MBSEN timeslots continue to use the 
scrambling codes associated with the cell ID. The timeslots that are operating in the MBSEN mode form together with 
the synchronized neighbouring cells transmitting the exactly same data the over the MBSEN cluster. 

Eor EDD, Node-Bs participating in an MBSEN transmission do so on all slots of the radio frame. Thus, MBSFN 
transmission occupies an entire carrier in the case of FDD, whereas for TDD, part or all of the carrier may be used for 
MBSFN. 

In addition, MBSFN Integrated Mobile Broadcast (3.84 Mcps TDD MBSFN 1MB) is defined. In this configuration, the 
downlink physical channels for the MBSFN option are mapped on a 3.84 Mcps TDD carrier frequency [10]. RE channel 
spacing according to the 3.84 Mcps TDD option is used. The entire carrier is used downlink for the 3.84 Mcps TDD 
MBSFN 1MB transmission. For the Node B, the transmitter RE requirements defined for the 3.84 Mcps TDD carriers 
apply. For the UE, the receiver RE requirements defined for the 3.84 Mcps TDD carriers apply. A primary 
synchronisation code shall be used, which is orthogonal to the primary synchronisation code used in normal 3.84 Mcps 
TDD configurations. Unless specified otherwise, the RRC and the MAC protocols are operated according to the FDD 
requirements applicable for MBSFN. 

It shall be possible for UEs supporting MBSFN to receive MBMS via carriers operating in FDD or TDD MBSFN mode 
and to also obtain unicast and MBMS (those not provided via MBSFN) by another carrier. 

Allied to MBSFN is the use of higher order modulation techniques (16QAM) for S-CCPCH and in the case of 3.84/7.68 
Mcps TDD only the use of a new burst type to support longer delay spread. In case of 3.84 Mcps TDD MBSFN 1MB, 
there are two types of S-CCPCHs: S-CCPCH frame typel and S-CCPCH frame type2. S-CCPCH frame type 1 consists 
of 15 slots per radio frame and uses a channelisation code of spreading factor 256. EACH carrying MCCH is mapped 
onto S-CCPCH type 1. S-CCPCH frame type 2 uses channelisation codes of spreading factor 16 and consists of 5 sub- 
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frames per radio frame; each sub-frame consisting of 3 slots. S-CCPCH frame type 2 is used to support short duty 
cycles on MTCH. The FACH carrying MTCH may be mapped onto one or more codes of spreading factor 16. 

Reception of MBMS services over a network operating in MBSFN mode implies that the UE is registered to a PLMN in 
order to perform higher layer procedures such as subscription to MBMS broadcast services. The means by which a UE 
obtains details of services provided, subscribes to those services it is interested in and obtains any ciphering keys 
necessary to decrypt services and/or means by which the services are delivered (MBSFN mode, frequency band used 
etc.), is considered to be outside the scope of 3GPP specifications. However, it is envisaged that the UE may obtain 
service details via a point-to-point connection via the carrier that is used to provide unicast services. 

The UE selects a MBSFN cluster to receive MBMS service that is part of one of the registered PLMN or part of the 
equivalent PLMN list. (Note: Network sharing is supported on carriers operating in MBSFN mode using the possibility 
to broadcast multiple PLMNs in the MIB just as it supported on carriers supporting unicast services) 

For the MBSFN cluster in 1.28 Mcps TDD mode, the UE that needs receive MBMS services delivered in an MBSFN 
cluster may first get synchronized to the non MBSFN cell that the MBSFN cluster is associated with and then search the 
MBSFN cluster with the information indicated in the system information of the non MBSFN cell. From the UE"s 
perspective, the registered PLMN of the MBSFN cluster should be the same as the PLMN that is registered by the UE 
from the associated unicast carrier. 

A MBSFN cluster provides only MBMS service in PtM mode. Counting and PtP establishment procedures are not 
supported for a cell operating in MBSFN mode. 

For FDD, 3.84 Mcps TDD 1MB and 3.84/7.68 Mcps TDD, the selection between MBSFN clusters is performed 
similarly to the way that cell selection is performed for cells that are not operating in MBSFN mode. The UE shall meet 
the minimum performance requirements specified for the reception of a MBMS cluster. The UE may consider a 
minimum receive power of the CPICH (FDD and 3.84 Mcps TDD 1MB) or P-CCPCH (3.84/7.68 Mcps TDD) in order 
to determine when to receive MBMS service broadcast in MBSFN mode. However apart from background search 
procedures for receiving other MBSFN clusters the UE is not required to perform inter-frequency measurements for 
other MBSFN clusters. Hierarchical cell structure, rules for fast moving UEs and inter-frequency and inter RAT 
measurements are not applicable for the cell operating in MBSFN mode. The intra frequency measurements for the 
reselection between MBSFN clusters are not specified. 

In a MBSFN cluster only MIB, system information blocks 3, 5/5bis and 1 1 may be broadcast. The content of other 
system information blocks is ignored by the UE. 

A MBSFN cluster on one frequency might indicate the existence and the services provided by other MBSFN clusters on 
different frequencies. The MBSFN cluster on one frequency may also indicate other MBSFN frequencies that have to 
be selected in order for the UE to be aware of available services that are not provided via the currently selected MBSFN 
cluster and for which the availability can not be indicated on the current MBSFN cluster. The choice of the MBSFN 
frequency based on this information is UE implementation specific. Because inter frequency measurements for MBSFN 
frequencies are not applicable the choice of the MBSFN frequency done by the UE may be completely service 
dependant. For FDD, 3.84 Mcps TDD 1MB and 3.84/7.68 Mcps TDD the UE only has to discover one MBMS cluster 
on another frequency that fulfils the selection criteria. Other frequencies on which MBMS service is broadcast in 
MBSFN mode is indicated on the MBSFN frequency. 

A cluster operating in MBSFN mode does not provide paging information because the MBSFN cluster will not be 
considered as a suitable cell by the UE. 

The cells in a MBSFN cluster belong to different MBMS service areas compared to the cells of a carrier providing 
unicast service. This allows the RNC to know which services are intended for the transmission on the cells of a MBSFN 
cluster. The same MBMS bearer service is not provided on a MBSFN cluster and the unicast cells. 

The minimum MBMS service area must be equal to one MBSFN cluster. A MBMS bearer service must be transmitted 
in a complete MBSFN cluster. 

7.1 A.1 3.84 / 7.68 MCPS TDD MBMS over a Single Frequency Network 
(MBSFN) 

A TDD UE operating on a carrier not dedicated to MBSFN shall follow MBMS procedures specified with respect to the 
RRC states (see Section 10). For TDD carriers not dedicated to MBSFN, MBMS services may be delivered via MBSFN 
and/or non-MBSFN means. In the case that any non-MBSFN transmissions are used to deliver MBMS services, the 
MCCH should not be transmitted via MBSFN means. 
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The reception of MBMS on a cell operating in MBSFN mode is independent to the UE behaviour for the reception of 
service on the frequency that the UE is camping on for obtaining unicast or MBMS service. For the reception of MBMS 
service on a TDD cell dedicated to MBSFN operation the UE is conceptually an independent component which receives 
MBMS service on a TDD cell dedicated to MBSFN. 

The TDD component of a UE for receiving MBMS service on a TDD carrier dedicated to downlink MBSFN shall: 

receive services provided via MBSFN independently of RRC state transitions for any non-MBSFN 
component of the UE 

obtain details concerning the MCCH provided via the BCCH of the cell providing MBSFN and listen to 
that MCCH for details of MBMS services provided p-t-m on the TDD DL-only carrier 

search for a suitable TDD MBSFN cluster providing the MBMS services that it is interested in: 

o is only required to support BCH and EACH transport channels and physical channels P-CCPCH, S- 
CCPCH, SCH on the TDD carrier 

o may optionally support MICH on the TDD carrier 

o shall expect to receive S-CCPCH configuration information via System Information Block 5 (the UE 
shall expect to receive System Information blocks 3, 5 and 1 1 only in addition to the Master 
Information Block) via the BCH on the TDD carrier. 

7.1 A.2 FDD MBMS over a Single Frequency Network (MBSFN) 

A FDD UE operating on a carrier not dedicated to MBSFN shall follow MBMS procedures specified with respect to the 
RRC states (see Section 10). 

The reception of MBMS on a cell operating in MBSFN mode is independent to the UE behaviour for the reception of 
service on the frequency that the UE is camping on for obtaining unicast or MBMS service. For the reception of MBMS 
service on a FDD cell dedicated to MBSFN operation the UE is conceptually an independent component which receives 
MBMS service on a FDD cell dedicated to MBSFN. 

The FDD component of a UE operating in a receive-only mode on a FDD carrier operating in MBSFN mode shall: 

receive services provided via MBSFN independently of RRC state transitions for any non-MBSFN 
component of the UE 

obtain details concerning the MCCH provided via the BCCH of the cell providing MBSFN and listen to 
that MCCH for details of MBMS services provided p-t-m on the FDD DL-only carrier 

search for a suitable FDD MBSFN cluster: 

o is only required to support BCH and EACH transport channels and physical channels P-CCPCH, S- 
CCPCH and SCH on the FDD carrier 

o may optionally support MICH on the FDD carrier 

o shall expect to receive S-CCPCH configuration information via System Information Block 5 (the UE 
shall expect to receive System Information blocks 3, 5 and 1 1 only in addition to the Master 
Information Block) via the BCH on the FDD carrier. 

7.1 A.3 1 .28 MCPS TDD MBMS over a Single Frequency Network (MBSFN) 

A TDD UE operating on a carrier not dedicated to MBSFN shall follow MBMS procedures specified with respect to 
the RRC states (see Section 10). For TDD carriers not dedicated to MBSFN, MBMS services may be delivered via 
MBSFN and/or non-MBSFN means. In the case that any non-MBSFN transmissions are used to deliver MBMS 
services, the MCCH should not be transmitted via MBSFN means. 

The reception of MBMS on a cell operating in MBSFN mode is independent to the UE behaviour for the reception of 
service on the frequency that the UE is camping on for obtaining unicast or MBMS service. For the reception of MBMS 
service on a TDD cell dedicated to MBSFN operation the UE is conceptually an independent component which receives 
MBMS service on a TDD cell dedicated to MBSFN. 
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The TDD component of a UE for receiving MBMS service on a TDD carrier dedicated to downlink MBSFN shall: 

receive services provided via MBSFN independently of RRC state transitions for any non-MBSFN 
component of the UE 

obtain details concerning the MCCH provided via the BCCH of the cell providing MBSFN and listen to 
that MCCH for details of MBMS services provided p-t-m on the TDD DL-only carrier 

search for a suitable TDD MBSFN cluster providing the MBMS services that it is interested in: 

o is only required to support BCH and EACH transport channels and physical channels P-CCPCH, S- 
CCPCH on the TDD carrier 

o may optionally support MICH on the TDD carrier 

o shall expect to receive S-CCPCH configuration information via System Information Block 5 (the UE 
shall expect to receive System Information blocks 3, 5 and 1 1 only in addition to the Master 
Information Block) via the BCH on the TDD carrier. 

NOTE: For 1.28 Mcps TDD, if a cell is operating in MBSFN mode, system information and MCCH messages are 
transmitted through the Special Timeslot [10]. 

7.1 A.4 3.84 Mcps TDD 1MB MBMS over a Single Frequency Network 
(MBSFN) 

A 3.84 Mcps TDD MBSFN 1MB capable UE operating on an FDD or 3.84/7.68 Mcps TDD carrier not dedicated to 
MBSFN shall follow MBMS procedures specified with respect to the RRC states (see Section 10). 

The reception of MBMS on a cell operating in MBSFN mode is independent to the UE behaviour for the reception of 
service on the frequency that the UE is camping on for obtaining unicast or MBMS service. For the reception of MBMS 
service on a cell dedicated to 3.84 Mcps TDD MBSFN 1MB operation, the UE is conceptually an independent 
component which receives MBMS service on a cell dedicated to 3.84 Mcps TDD MBSFN 1MB. 

The 3.84 Mcps TDD MBSFN 1MB component of a UE receiving MBMS service on a 3.84 Mcps TDD carrier dedicated 
to 3.84 Mcps TDD MBSFN 1MB shall: 

receive services provided via MBSFN independently of RRC state transitions for any non-MBSFN component 
oftheUE; 

- obtain details concerning the MCCH provided via the BCCH of the cell providing 3.84 Mcps TDD MBSFN 
1MB and listen to that MCCH for details of MBMS services provided p-t-m on the 3.84 Mcps TDD carrier 
dedicated to 3.84 Mcps TDD MBSFN 1MB; 

search for a suitable MBSFN cluster providing the MBMS services the UE has activated: 

o is only required to support BCH and EACH transport channels and physical channels P-CCPCH, S-CCPCH 
frame type 1, S-CCPCH frame type 2 and SCH on the 3.84 Mcps TDD carrier dedicated to 3.84 Mcps TDD 
MBSFN 1MB; 

o may optionally support MICH on the 3.84 Mcps TDD carrier dedicated to 3.84 Mcps TDD MBSFN 1MB; 

o shall expect to receive S-CCPCH frame type 1 configuration information via System Information Block 5 
(the UE shall expect to receive System Information blocks 3, 5 and 1 1 only in addition to the Master 
Information Block) via the BCH on the 3.84 Mcps TDD carrier dedicated to 3.84 Mcps TDD MBSFN 1MB. 
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7.1 B MBMS in case of inter-RNC synchronization 

7.1 B.1 Control Plane aspects 

7.1 B.1 .1 MBMS Parameter Configurations 

The common parameters in MBMS P-t-M RB configurations shall be configured in each RNC semi-static manner via 
O&M. 

The parameters, transmitted in RRC; MBMS Common P-T-M RB Information and to be configured, are: 

RB Information list 

- RB identity 

- PDCP info 

- RLC info 

TrCh information for each TrCH 
Transport channel identity 

- TFS 

TrCh information for each CCTrCh 

- CCTrCH identity 

- TFCS 

In case of soft combining the Secondary CCPCH configurations shall be aligned between the neighboring cells. 
IncaseofMBSFN: 

If MBMS services are controlled statically, the parameters to be configured for MBSFN: 
PhyCh information 

- PhyCh identity 

- Secondary CCPCH info MBMS 

.In the case the used parameter value in a cell may depend on the received RAB QoS and/or MBMS service area ID 
and/or TMGI value, the mapping information should be configured via O&M. Such mapping information should be 
available in RNCs before the MBMS session setup. 

If MRNC is used, the parameters shall be configured by MRNC, and the MRNC shall inform CRNC of the 
configuration and mapping information of MBMS service to RB information at session start. 

In addition to parameters used for air interface, the pool of DL TEIDs used for the MBMS transmission on lu carried by 
IP-multicast distribution shall be configured in all RNCs by O&M. The stored DL TEIDs used in IP multicast 
distribution shall not be used by the RNC for any other transmission. 

7.1 B.1 .2 MBMS Counting and mode switch coordination 

The RNC shall generate the MBMS Counting procedure towards UEs as in case of intra-RNC selective/soft combining 
(see section 5.2.5). 

If the RNS controlled by a RNC is smaller than the possible selective / soft combining area, the status of the cells in 
surrounding RNC that are part of the selective/soft combining area should be known before deciding on the own 
transmission mode. Therefore the RNC shall exchange the transmission mode and counting information with the 
neighbouring RNCs, which are controlling cells part of the same selective/soft combining area as the cells controlled by 
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the current RNC. Also the neighbour cells indicated for selective/soft combining in MBMS NEIGHBOURING CELL 
P-T-M RB INFORMATION message have to be coordinated between RNCs. 

The RNSAP function, Information Exchange is used for counting and mode switch coordination. 

The RNC may request for the counting results and transmission mode information in cells controlled by a neighbour 
RNC by sending the INFORMATION EXCHANGE INITIATION REQUEST message to the relevant neighbouring 
RNCs. 

For counting the INFORMATION EXCHANGE INITIATION REQUEST message will contain the information about 
the cells controlled by the sending RNC, for which the sending RNC have requested counting. The RNC receiving the 
INFORMATION EXCHANGE INITIATION REQUEST message shall first identify if any of the cells received in the 
message is announced as a neighbour cell for the MBMS service in the cells controlled by the receiving RNC (own 
cells). Thereafter the receiving RNC shall perform counting in these own cells and inform sending RNC about the result 
over lur in the INFORMATION EXCHANGE INITIATION RESPONSE message. 

For MBMS transmission mode change the INFORMATION EXCHANGE INITIATION REQUEST message will 
contain information about the cells controlled by the sending RNC ("initiating cell list") and the TMGIs for which the 
MBMS transmission mode are requested to be reported when the transmission mode is changed. The MBMS 
transmission mode shall be reported for cells under control of the RNC receiving the INFORMATION EXCHANGE 
INITIATION REQUEST message. The MBMS transmission mode for the TMGIs in the INFORMATION 
EXCHANGE INITIATION REQUEST message shall be reported for the cells that have a configured neighbour 
relation to the cells in the "initiating cell list". 

The RNC initiating the Information Exchange Initiation procedure shall use the received MBMS transmission mode 
information of the neighbour cells under control of another RNC to update MBMS NEIGHBOURING CELL P_T_M 
RB INFORMATION message content of its own cells. 

7.1 B.1 .3 Control Plane Coordination at MBMS Session Start 
7. 1 B. 1 .3. 1 Coordination of neighbor cell configuration 

The RNC shall at MBMS session start in its own cells, being part of the targeted MBMS service area, activate the 
RNSAP Information Exchange Initiation procedure to all neighboring RNCs, which are controlling cells allowed to be 
used for selective/soft combining with the relevant own cells of the RNC. The response, INFORMATION 
EXCHANGE INITIATION RESPONSE and INFORMATION REPORT messages shall contain the copy of the RRC 
containers, which were sent out on MCCH announcing the active MBMS session and for each MBMS session that is 
started a list of cell identities in which the MBMS session (identified with TMGI) was setup. 

The receiving RNC shall identify based on the received information the valid neighbor cells for soft/selective 
combining in the RNC, which is the sender of the message for the new MBMS session, and retrieve the S-CCPCH 
configuration in those neighboring cells. Finally the MBMS COMMON P-T-M RB INFORMATION shall be updated 
with the received S-CCPCH configuration information and the neighboring cells are announced in MBMS 
NEIGHBOURING CELL P-T-M RB INFORMATION. 

As part of the 'Valid neighbor cell identification' the RNC shall verify that the configuration of the cells of the sending 
RNC is aligned and possible for soft combining, e.g. that the MBMS logical channel id is aligned for all MBMS 
sessions. The RNC shall not accept the cell as neighbor cell if not aligned. The consequence of a mismatch is that the 
soft/selective combining gain is lost for this MBMS session, but as this abnormal condition only occurs rarely it is 
regarded as acceptable. 

Coordination of MBMS configurations after RNC restarts 

In case of restart the RNC may loose all the MBMS configurations of its cells as well the neighbor cell MBMS 
information and any other MBMS related parameters. 

The RNC will recover from that situation by getting the MBMS configurations updated in a three phase approach: 

1 . via O&M the MBMS service configurations for its cells. In addition to the MBMS service area configurations 
there are other parameters which can be configured semi-static manner via O&M system like indicated above. 

2. As part of the general restart procedure the SGSN will send the Session Starts for all ongoing MBMS sessions to 
the RNC. RNC will respond to the MBMS Session Start messages normal manner in line with the MBMS 
service area configurations of its cells. 
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3. After the RNC has become aware of the active MBMS sessions it will identify the relevant neighboring RNCs 
which should be contacted to retrieve the necessary parameters for the neighbor cell configuration. 

7.1 B.1 .4 MCCH synchronization in an MBSFN cluster 

To synchronize MCCH dynamically, the logical entity "MBMS Master RNC" may be introduced to control the 
resources of the RNSs within the MBSFN cluster(s). There"s only one MBMS Master RNC for any MBSFN cluster. 
The other RNC can be seen as the CRNC. 

If MRNC is used, the RNSAP procedure "MBSFN MCCH Information" is used to transfer information between MRNC 
and CRNC to synchronize the MCCH. 

7.1 B.2 User Plane aspects 
7.1 B. 2.1 Timing requirements 

The soft combining and MBSFN mode across RNCs will require similar timing requirements between the cells 
controlled by different RNCs as what is required for cells part of same RNC in Rel-6 and Rel-7. The summary of the 
timing requirements is presented in the table below. 

Table 7.1 B.2. 1-1 The table summarizes the timing requirements for WCDMA MBMS 



Functionality 


Release 


Timing requirement 


MBMS 40 ms TTI 


3GPP Release 6 


40.667 ms 


MBMS 80 ms TTI 

MBMS with single frequency 

network support (MBSFN) 


3GPP Release 6 
3GPP Release 7/8 


80.667 ms 
12.8 microseconds 



There are several ways to synchronize the network elements to a common reference time: which meet Rel6/MBSFN 
timing requirements. 

• 3GPP synchronization in UTRAN, 

• Network Time Protocol (NTP), 

• Relying on IP multicast distribution, 

• Global positioning system (GPS), 

• IEEE1588. 

All the listed synchronisation methods may be used but the provided accuracy could be dependent on the 
synchronisation deployment solution_ 

7.1 B.2. 2 MBMS User Data flow synchronization 

The synchronized radio interface transmission from the cells controlled by different RNCs require a SYNC-protocol 
support over the lu-interface between the BM-SC and the RNCs. 

As part of the SYNC-protocol procedure the BM-SC shall include to the SYNC PDU packets a time stamp which tells 
the timing based on which the RNC sends MBMS data over air interface. This time stamp is based on a common time 
reference available at the BM-SC and the RNCs and represents a relative time value which refers to the start time of the 
synchronisation period. 

MBMS user data shall be time-stamped based on separable synchronization sequences which are tied to multiples of the 
TTI length. Synchronization sequence is transmitted continuously, even if there is no MBMS user data in the 
synchronization sequence. Each synchronization sequence for each service is denoted by a single timestamp value 
working in such a manner that an increase of the timestamp value by one synchronisation sequence length shall be 
interpreted as an implicit start-of-a-new-synchronization-sequence-indicator, so that the RNC becomes aware that a new 
sequence is starting. For additional robustness, the timestamp shall be replicated to all packets that shall be submitted 
over the air interface within one or multiple TTIs. 
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When adding the Time Stamp the BM-SC should take into account following factors: arrival time of data, the 
Maximum Transmission Delay from BM-SC to the farthermost RNC, the length of the synchronization sequence used 
for time stamping and other extra delay (e.g. processing delay in RNC and NodeB ). The parameters "Max Tx Delay", 
"synchronization sequence length" and "Other Extra Delay" are set via O&M in BM-SC. 

The BM-SC does not know the absolute time point at which a TTI starts, but the sequence length for the time stamp is 
set by O&M like the delay parameters. The BM-SC will use the delay parameters to define the transmission time point 
of that user data packet and for the following user data packets the sequence length for the time stamp: following user 
data packets arriving within e.g. 40ms will receive the same time stamp value as the first data packet, if the sequence 
length is set to be 40 ms. 

The RNC shall schedule the received data packets in the TTIs following the time point indicated by the timestamp. 

NOTE: From the timestamp the RNC can interpret the TTI from which the transmission of the first user data 

packet with that time stamp value shall start. Whether there will be data packets to be transmitted in the 
following TTIs will depend on the used synchronization sequence length vs. the TTI length and on the 
user data flow. 

In case MRNC is used and TDM multiplexing is used over air interface, scheduling transmission time interval is 
defined as a time interval of the minimal common multiple of synchronization sequence length and TDM period (CFN 
period shall be divided by TDM period) in the MRNC. The MRNC shall inform the scheduling transmission time 
interval to the RNCs over lur together with MCCH message. The RNC shall schedule received data packets in the 
scheduling transmission time interval following the time point indicated by the timestamp. If multiple synchronization 
sequences are to be transmitted consecutively in one scheduling transmission time interval, these synchronization 
sequences shall be processed as if they are a single synchronization sequence. 

In case MRNC is not used and TDM is used over air interface, the synchronization sequence length should be 
configured to be multiples of the TDM Period (CFN period shall be a multiple of the TDM period). 

The elementary procedures related to the SYNC -protocol are defined in [14]. 

In addition to the Time Stamp parameter the BM-SC shall provide together with each MBMS User data packet the 
'Packet Counter' and 'Elapsed Octet Counter' information. Based on these parameters the RNC is able to notice if any 
data packets were lost during transmission via IP Multicast and to know the size of the lost payload, in case of a single 
packet is lost. Additionally the RNC is able to reorder the PDUs before passing them to RLC processing, if needed. 

At the end of each synchronization sequence the BM-SC shall send to the RNCs at least one user data frame, which 
contains counter information including 'Total Number Of Packet Counter' and 'Total Number Of Octet without MBMS 
payload. This Total Counter frame is implicitly marking the end-of-sync.seq.. The Total Counter frame without payload 
may be repeated in order to improve the reliability of the delivery to the RNCs. 

If neither Total Counter frame nor data Frame is received by a RNC for a synchronization sequence, the RNC shall 
regard the whole synchronization sequence data frame as lost. 

7.1 B.2.3 User Plane recovery in case of Multiple Packets Loss 

In case multiple contiguous SYNC PDUs are lost in the RNC, the division of payload between the lost packets is not 
necessarily known by the RNC. This may lead to an incorrect RLC SN value usage in the RNC, when handling the first 
data packet received from BM-SC after the multiple packet loss. The RNC is able to notice the loss of multiple user 
data packets based on the "Packet Counter" information delivered by the SYNC-protocol together with the user data 
packets. In such a situation the radio interface transmission should be avoided until the RNC is able to resynchronize its 
transport block creation with the neighbouring RNCs or the radio interface transmission may be avoided for exact 
TTI(s) impacted by the lost SYNC PDUs using the help of the length information of the lost SYNC PDU provided by 
SYNC protocol. 

In case of soft combining and MBSFN mode the RNC resynchronization is supported by the RLC SN reset at the start 
of each synchronization sequence in all RNCs part of the IP Multicast distribution. The RNCs are able to notice the start 
of the synchronization sequence from the new time stamp value and the packet counter information received from BM- 
SC. 

In case MRNC is used and TDM multiplexing is used over air interface, the RNC re-synchronization is supported by 
the RLC SN reset at the start of each scheduling transmission time interval signalled from MRNC in all RNCs part of 
the IP Multicast distribution. 
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In case of selective combining the RNC shall request from the neighbouring RNCs, which are used for selective 
combining for that particular MBMS stream, the correct RLC SN value to be used for the first RLC PDU of the next 
synchronization sequence. 



7.2 UE Capability 



The UE MBMS capability is not sent to UTRAN and is subject to UE implementation, including the relation between 
MBMS capability and actual RRC state which is also a UE implementation. A consequence is that a UE may be 
counted although its actual capability does not allow to receive MBMS transmissions e.g. because of its current RRC 

state. 

The standard will describe a minimum UE capability requirement in order to allow operators to configure MBMS 
channels that can be common to all UEs supporting the given service. 

There are some UE capability requirements that are common to all eventual service categories; 

The minimum UE capability for MBMS capable UE, is one primary CCPCH plus all the configurations below. The UE 
is not required to support these configurations simultaneously. 

1 . One PICH and one MICH 

2. One S-CCPCH and one MICH 

3. One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and two S-CCPCH with 
80ms TTI for MTCH reception 

4. One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and three S-CCPCH with 
40ms TTI for MTCH reception 

5. One PICH and two S-CCPCH with 80ms TTI for MTCH reception 

6. One PICH and three S-CCPCH with 40ms TTI for MTCH reception 

The requirement one reflects the case when the UE is in Idle mode, or URA_PCH, CELL_PCH state and MBMS 
reception is not ongoing and requirement five and six are for the case that MBMS reception is ongoing in Idle mode, or 
URA_PCH, CELL_PCH state. 

The requirement two reflects the case when the UE is in CELL_EACH state and MBMS is reception not ongoing and 
requirement three and four are for the case when MBMS reception is ongoing respectively. 

The requirement for the number of simultaneous S-CCPCHs for MTCH reception includes those S-CCPCHs for which 
combining is performed. 

When MBMS ptm reception is ongoing, the UE is required to periodically monitor the MCCH, which may be mapped 
onto a different S-CCPCH from MTCH, and a different S-CCPCH than the R"99 EACH when the UE is in 
CELL_EACH state. However this does not increase the requirement for the number of S-CCPCHs to be simultaneously 
received by the UE. 

The abihty of the UE to receive DPCH/HS-PDSCH simultaneously with S-CCPCH carrying MTCH/MCCH is subject 
to UE capability. 

The minimum MBMS bit rate that all MBMS capable UEs shall support is to be defined [12]. 

For FDD, the UE shall support selective combining and soft combining on cells not indicating that they provide MBMS 
service in MB SEN mode. 

For FDD and 3.84 Mcps TDD 1MB, the UE is not required to support selective combining and soft combining on cells 
indicating that they provide MBMS service in MBSEN mode. 

For a TDD UE supporting both transmit and receive functions, selective and soft combining shall be supported. For a 
3.84 / 7.68 Mcps TDD UE supporting both transmit and receive functions, MBSEN operation shall also be supported. 
For a UE supporting 3.84 / 7.68 Mcps TDD MBSEN receive only, support for selective combining and soft combining 
is not required. 

The standard may restrict further the UE implementation options by defining certain capability combinations. 
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If the UE is supporting MBMS ptm reception in CELL_DCH state, it shall have capability to acquire MCCH 
configuration from BCCH after handover procedure, and after that receive MCCH and MTCH. 

7.3 MBMS Reception 

The following descriptions add MBMS specific processes to be considered for each RRC State/Mode. 

The BCCH contains information regarding the MCCH, while the latter contains information on the MTCH. 

In the sub-sections below, how and when the UE reads the MCCH is not described as periodic MCCH transmission is 
described in section 5.2.3. 

The reception of multiple MBMS services simultaneously is subject to UE capability; selection principles between 
MBMS services are defined in section 5.2.8. The specific actions related to MBMS session repetition are specified in 
section 5.2.7. 

7.3.1 MBMS Reception in RRC Idle Mode 

In idle mode, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH and: 

- if the MBMS service requires the establishment of an RRC Connection due to counting response or due to the 

utilisation of p-t-p transfer mode for the MBMS service: 

- inform upper layers that the MBMS Service requires the establishment of an RRC Connection. 

- if the MBMS service does not require the establishment of an RRC Connection : 

- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell: 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.2 MBMS Reception in RRC Connected Mode: URA_PCH state 

In URA_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the URA where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH, 

- if on the MCCH it is indicated that the MBMS service in the cell requires a counting response or is due to 

the utilisation of p-t-p transfer mode for the MBMS service: 

- initiate a cell update procedure, for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 
MODIFICATION REQUEST signalling flow. The cause to be used in the cell update procedure is 
defined in [13]. 

- for each MBMS service that the UE has activated and where transmission on a MTCH is indicated in the 

MCCH, listen to the common transport channel on which the MTCH is mapped, 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 
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- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.3 MBMS Reception in RRC Connected Mode: CELL_PCH state 

In CELL_PCH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 

- if on the MCCH it is indicated that the MBMS service in the cell requires counting response or is due to the 

utilisation of p-t-p transfer mode for the MBMS service: 

- initiate a cell update procedure for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 
MODIFICATION REQUEST signalling flow. The cause to be used in the cell update procedure is 
defined in [13]. 

- listen to the common transport channel on which the MTCH is mapped, 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 

7.3.4 MBMS Reception in RRC Connected Mode: CELL_FACH state 

In CELL_FACH, the UE shall: 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available 

- act on RRC messages received on MCCH 

- if on the MCCH it is indicated that the MBMS service in the cell requires a counting response or is due to 

the utilisation of p-t-p transfer mode for MBMS service: 

- initiate a counting response for sending MBMS COUNTING RESPONSE, or MBMS P-T-P 
MODIFICATION REQUEST signalling flow. 

- listen to the common transport channel on which the MTCH is mapped 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_FACH, UTRAN may decide to send MBMS data over DTCH. 

7.3.5 MBMS Reception in RRC Connected Mode: CELL_DCH state 

In CELL_DCH, the UE shall, 

- if the UE supports MBMS and 

- if the UE has activated an MBMS service and there is an ongoing session for this service in the cell where the UE 
is situated, i.e. MTCH and MCCH are available and 

- if the UE has the capabilities: 

- act on RRC messages received on MCCH 
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- listen to the common transport channel on which the MTCH is mapped. 

- if the UE determines that a neighbouring cell is suitable for selective or soft combining and the UE has valid 

MBMS NEIGHBOURING CELL INFORMATION of that cell and UE has capability 

- performs selective or soft combining of MTCH between the selected cell and the neighbouring cell. 
NOTE: For UEs in CELL_DCH, UTRAN may decide to send MBMS data over DTCH 



8 UTRAN Signalling Flows for MBMS 

8.1 MBMS High Level Signalling Scenarios 
8.1.1 Session start 

Upon receiving a session start indication from CN, UTRAN initiates the session start sequence to allocate radio 
resources to UEs for receiving the MBMS content. As part of this sequence, UTRAN may apply the counting procedure 
(counting the number of idle mode, URA_PCH, CELL_PCH and CELL_FACH state UEs) to decide whether to use the 
p-t-m or p-t-p transfer mode. For MBMS Broadcast mode, the applicability of the counting procedure for a service is 
indicated by the CN. 

The Figure 8.1.1 shows an example of a possible session start sequence. 



UE 



UTRAN 



1 . Notification for session start 



2. IVIBIVIS RB (IVITCH, DTCH) establisliment 



3. IVIBIVIS data transfer 



Figure 8.1 .1 : Session start 

In general, the session start sequence involves the following steps: 

• In case UTRAN applies counting to determine the most optimal transfer mode the following steps are performed: 

o UTRAN sets the correct MBMS Notification Indicator (NI) and sends the MBMS CHANGE 

INFORMATION and the MBMS ACCESS INFORMATION including service ID, the session ID if 
received from the CN, and access probability on MCCH. 

o Upon DRX wakeup, UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH not 
receiving an MBMS service provided in p-t-m transfer mode evaluate the MBMS NI and if set, read the 
MBMS CHANGE INFORMATION from MCCH at beginning of the modification period. UEs in idle 
mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service provided 
in p-t-m transfer mode read the MBMS CHANGE INFORMATION directly. If service Id of activated 
MBMS service and session ID that the UE has not received is indicated in MBMS CHANGE 
INFORMATION UEs continue reading the rest of MCCH information. Upon receiving the MBMS 
ACCESS INFORMATION including access probabihty, UEs in idle mode or URA_PCH, CELL_PCH, 
and CELL_FACH state for which the probability check passes, initiate counting response. UTRAN counts 
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the UEs with an activated MBMS service by combining the UE linking from CN and received counting 
responses from UEs. 

o In the case that no UE is counted as present in the cell then UTRAN may decide not to provide any RB for 
the service in the cell. 

o In case a pre- defined threshold is reached, UTRAN applies the p-t-m RB establishment procedure 
specified below. Otherwise, UTRAN may repeat the MBMS ACCESS INFORMATION a number of 
times, using different probability values. If the threshold is not reached, UTRAN applies the p-t-p RB 
establishment procedure 

• In case UTRAN selects the p-t-m RB establishment procedure: 

o UTRAN configures MTCH and updates MCCH (MBMS SERVICE INFORMATION and MBMS 

RADIO BEARER INFORMATION) by including the service ID, the session ID if received from the CN, 
and p-t-m RB information for the concerned MBMS service 

o In case p-t-m RB establishment is not preceded by counting, UTRAN sets the correct MBMS Notification 
Indicator (NI) and sends MBMS CHANGE INFORMATION. 

o UTRAN sends the MBMS dedicated notification message including the service ID and cause= session 
start on DCCH to inform UEs in CELL_DCH that are not receiving an MBMS service provided using p-t- 
m transfer mode 

o In case p-t-m RB establishment is preceded by counting, UEs read MCCH at the pre- defined time(s) to 
acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION 

o In case p-t-m RB establishment is not preceded by counting. Upon DRX wakeup, UEs not receiving 
MTCH evaluate the MBMS NI and if set, read MCCH at beginning of modification period to acquire 
MBMS CHANGE INFORMATION. UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and 
CELL _FACH receiving an MBMS service provided in p-t-m transfer mode read the MBMS CHANGE 
INFORMATION directly. If service Id of activated MBMS service and session ID that the UE has not 
received is indicated in MBMS CHANGE INFORMATION UEs continue reading the rest of MCCH 
information to acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION 

o UEs that are incapable of receiving the MTCH for the session that is started in parallel to the existing 
activity notify the user. This enables the user to choose between the ongoing activity and the new MBMS 
service 

o Upon receiving MBMS dedicated notification with cause= session start, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the user. This enables the user to choose between the ongoing activity and the new MBMS service. If the 
user decides to receive the new MBMS service, the UE shall read MCCH to acquire the MBMS SERVICE 
INFORMATION and MBMS RADIO BEARER INFORMATION. 

o Upon receiving the MBMS SERVICE INFORMATION and the MBMS RB INFORMATION including 
the p-t-m RB information for the concerned MBMS service, the UE starts receiving the p-t-m radio 
bearers 

• In case UTRAN selects the p-t-p RB establishment procedure: 

o UTRAN indicates on MCCH in MBMS CHANGE INFORMATION that MBMS service is provided via 
p-t-p 

o After receiving MBMS CHANGE INFORMATION UEs with an activated MBMS service, after possible 
service priorisation, request MBMS p-t-p RB estabhshment by sending MBMS P-T-P MODIFICATION 
REQUEST signalling flow. 

o Furthermore, UTRAN establishes the p-t-p RB by means of appropriate RRC procedures e.g. the RB setup 
procedure 

o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure 
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o UTRAN updates MCCH (MBMS SERVICE INFO) to inform UEs joining or entering the cell at a later 
point in time. 

8.1 .2 Joining (during a session) 

In case the user wants to join an MBMS service (before or during a session), the UE initiates NAS procedures (e.g. 
MBMS service activation). 

If no session is ongoing upon completion of the joining procedure, the joining procedure is transparent to the AS. 

In case a session using p-t-m transfer mode is ongoing upon completion of the joining procedure, the UE may initiate 
reception of the p-t-m radio bearers. In case the ongoing session applies p-t-p transfer mode, UTRAN may establish the 
p-t-p radio bearers. UTRAN would do this upon receiving a UE linking indication from CN, which normally follows 
the joining. As a result of the UE linking, UTRAN may decide to change the transfer mode from p-t-p to p-t-m. This 
change of transfer mode is out of the scope of this sequence (to be covered by a separate sequence). 

The Figure 8.1.2 shows an example of a possible joining sequence. 



UE 



UTRAN 



1. Joining (NAS) 



2. Initiate reception of PTIVI RBs 



3. IVIBIVIS data transfer, PTM 



Figure 8.1.2: Joining withi continuation of p-t-m 

In general, the joining sequence involves the following steps: 

• UEs in idle mode first perform RRC connection establishment, while UEs in CELL_PCH and URA_PCH first 
perform cell update 

• UEs initiate the joining procedure (NAS) 

• In case UTRAN continues to use the p-t-m transfer mode: 

o UTRAN sends the MBMS dedicated notification message on DCCH including the service ID and cause= 
session ongoing to inform UEs in CELL_DCH 

o Upon receiving MBMS dedicated notification with cause= session ongoing, UEs in CELL_DCH that are 
incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity notify 
the upper layer. This enables the user to choose between the ongoing activity and the new MBMS service. 
If the user chooses to receive the new MBMS service or if the UE in Cell_DCH is capable of receiving 
MCCH and MTCH in parallel to the existing activity, the UE shall read MCCH to acquire the MBMS 
SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION from MCCH. 

o Upon acquiring the MBMS SERVICE INFORMATION and the MBMS RADIO BEARER 

INFORMATION including the p-t-m RB information for the concerned MBMS service, the UE starts 
receiving the p-t-m radio bearers 

• In case UTRAN continues using the p-t-p transfer mode: 

o UTRAN establishes the p-t-p RB by means of appropriate RRC procedures eg. the RB setup procedure 
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o UEs establish the p-t-p radio bearers by means of the RRC procedure selected by UTRAN eg. the RB 
setup procedure. 

8.1.3 Recounting 

During a p-t-m MBMS session, UTRAN may perform re- counting to verify if p-t-m is still the optimal transfer mode. 
The purpose of the re- counting procedure is to count the number of idle mode, URA_PCH, CELL_PCH, and 
CELL_FACH state UEs that have joined a specific service. As a result of this procedure, UTRAN may decide to change 
the transfer mode from p-t-m to p-t-p. This change of transfer mode is outside the scope of this sequence (to be covered 
by a separate sequence). 

The Figure 8.1.3 shows an example of a possible recounting sequence. 



UE 



MBMS data transfer, PTM 



1 . Notification for re-counting 



UTRAN 



2: Act based on messages received on 
MCCH 



MBMS data transfer, PTM 



Figure 8.1.3: Recounting with continuation of p-t-m 

In case UTRAN applies re- counting to determine the most optimal transfer mode, the following steps are performed: 

• UTRAN sends the MBMS CHANGE INFORMATION and the MBMS ACCESS INFORMATION including 
service ID, and access probability on MCCH 

• UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service 
provided in p-t-m transfer mode read the MBMS CHANGE INFORMATION at the beginning of each 
modification period. If service Id of activated MBMS service is indicated in MBMS CHANGE INFORMATION 
UEs continue reading the rest of MCCH information. 

• Upon receiving the MBMS ACCESS INFORMATION including access probabihty, UEs in idle mode or 
URA_PCH, CELL_PCH and CELL_FACH state for which the probability check passes, initiate counting response. 

• UTRAN counts the UEs with an activated MBMS service by combining the UE linking from CN and received 
counting responses from UEs. 

• In the case that no UE is counted as present in the cell then UTRAN may decide not to provide any RB for the 
service in the cell. 

• In case a pre- defined threshold is reached, UTRAN continues using the p-t-m transfer mode. Otherwise, UTRAN 
may repeat the MBMS ACCESS INFORMATION a number of times, using different probability values. If the 
threshold is not reached, UTRAN switches transfer mode from p-t-m to p-t-p 

• In case UTRAN continues using the p-t-m transfer mode, it may return UEs that responded to counting back to idle 
mode by releasing the RRC connection. 
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8.1.4 Session Stop 

UTRAN may apply the session stop procediire to inform UEs that the end of MTCH transmission concerns the end of a 
session rather than just an idle period. The purpose of the procedure is to reduce the UE power consumption. 

The Figure 8. 1 .4 shows an example of a possible session stop sequence. 



UE 



UTRAN 



1 . Termination of MBMS data transfer, PTM 



2. Notification for session stop 



Figure 8.1.4: Session stop 

In case UTRAN provides the service p-t-m, the session stop sequence involves the following steps: 

• UTRAN updates the MBMS CHANGE INFORMATION, MBMS SERVICE INFORMATION and the MBMS 
RADIO BEARER INFORMATION including the service ID and the explicit radio bearer release indicator. 
UTRAN updates MCCH (MBMS SERVICE INFORMATION) to inform UEs joining or entering the cell in a later 
point of time. 

• UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an MBMS service 
provided in p-t-m transfer mode read the MBMS CHANGE INFORMATION at the beginning of the each 
modification period. If service Id of activated MBMS service is indicated in MBMS CHANGE INFORMATION 
UEs continue reading the rest of MCCH information. 

• Upon receiving this information the UE stops receiving the MTCH 

In case UTRAN provides the service p-t-p, the session stop sequence involves the following steps: 

• UTRAN releases the p-t-p radio bearers and updates MCCH (MBMS SERVICE INFO) to inform UEs joining or 
entering the cell at a later point in time. 

8.2 MBMS RNC Signalling Flows 
8.2.1 IVIBIVIS Session Start procedure 



RNC 




CN 




4 tf 


^ANAP] MBMS SESSION STAF 


^T 








^ REQUEST 

[RANAP] MBMS SESSION START ^ 








RESPONSE 




w 





Figure 8.2.1 : IVIBIVIS Session Start procedure. Successful operation. 
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The MBMS Session Start procedure is initiated by the CN when an MBMS Session is started. The MBMS SESSION 
START REQUEST is sent to each RNC that is connected to the CN (in case of lu-flex the RNC may receive more than 
one MBMS SESSION START REQUEST message). 

The MBMS SESSION START REQUEST contains the MBMS Service Id, and optionally the MBMS Session ID, 
MBMS Bearer Service Type and the MBMS Session Attributes (MBMS Service Area Information, QoS parameters. . .) 
It may also include a list of RAs which lists each RA that contains at least one PMM-IDLE UE that has activated the 
service. 

MBMS Session Start procedure also provides the MBMS lu Data Bearer Establishment functionality. In case of lu-flex 
the RNC shall not establish more than one MBMS lu bearer for a certain service towards a pool area and shall inform 
the respective CN nodes accordingly. 

The MBMS Session Start procedure in case of IP Multicast is described in section 8.2.16. 



8.2.2 MBMS Session Update procedure 



RNC 




CN 




[RANAP] MBMS SESSION UPDATE 






^ REQUEST 

[RANAP] MBMS SESSION UPDATE ^ 








RESPONSE 


w 





Figure 8.2.2: MBMS Session Update procedure. Successful operation. 

The MBMS Session Update procedure is initiated by the CN when an MBMS Session is ongoing and SGSN notices 
that there is a need to update the list of RAs. The MBMS SESSION UPDATE REQUEST contains the MBMS Service 
Id, and e.g. List of RAs with PMM Idle UEs.. 

8.2.3 MBMS Session Stop procedure 



RNC 




CN 






[ 


RANAP] MBMS SESSION STO 


P 










REQUEST 
[RANAPl MBMS SESSION STOP 


k 










RESPONSE 









Figure 8.2.3: MBMS Session Stop procedure. 

This signalling flow depicts the MBMS Session Stop procedure. 

This procedure is initiated by the CN to the RNCs with an ongoing MBMS session, when no more data will be sent for 
that MBMS service for some period of time. 

The MBMS Session Stop procedure also provides the MBMS lu Data Bearer Release functionality. 
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8.2.4 RNC Registration procedure 



RNC 




CN 




[RANAP] MBMS REGISTRATION 






REQUEST ^ 
[RANAP] MBMS REGISTRATION 






^ 


RESPONSE 







Figure 8.2.4: MBMS Registration procedure. 

This signalling flow depicts the MBMS Registration procedure. 

This procedure is initiated by the RNC in the case that the RNC is not SRNC for any UE that has joined the MBMS 
Service, but this RNC is DRNC for PMM-CONNECTED UEs that have joined the MBMS Service and there is no 
MBMS Service Context for the MBMS Service in this RNC. 

This procedure shall be initiated by the DRNC, as soon as a UE link is received over the lur and there exists no MBMS 
Service Context for the MBMS service for which the UE link is received. 

8.2.5 RNC De-Registration procedure 



RNC 




CN 




[Ry 


^NAP] MBMS DE-REGISTRAT 


ON^ 






REQUEST 
^ [RANAP] MBMS DE-REGISTRATION 






^ 


RESPONSE 







Figure 8.2.5: RNC MBMS De-Registration procedure. 

This signalling flow depicts the RNC De-Registration procedure. This procedure is initiated by the RNC towards the 
CN node it was registered to in case the RNC is not acting as a Serving RNC for any UE that has activated the MBMS 
Service and has ceased to act as a Drift RNC for UEs which has activated an MBMS service. 

8.2.6 CN De-Registration procedure 



RNC 




CN 




4 [R' 


SiNAP] MBMS DE-REGISTRAT 


ON 






^ REQUEST 

[RANAP] MBMS DE-REGISTRATION ^ 








RESPONSE 


w 





Figure 8.2.6: CN MBMS De-Registration procedure. 

This signalling flow depicts the CN De-Registration procedure. 

This procedure is initiated by the CN in order to inform the RNC that a certain MBMS Service is no longer available. 
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8.2.7 MBMS Channel Type Switching over Uu 



UE 




CRNC 




SRNC 










MBMS CONTROL (p-t-p) 
















4 

^ 


MBMS DATA (p-t-m) 
MBMS DATA (p-t-m) 








* 
















CRNC determines to 
switch channel type 
from ptm to ptp 












1 












MBMS Channel Type Reconfiguration Signalling over lur 






[RRC] RB SETUP 






SRNC decides whether to 

perform channel type 

switching to p-t-p or not 
















[RRC] RB SETUP COMPLETE 








-4 


MBMS Data (p-t-p) 







Figure 8.2.7: Channel type switching signalling flow from p-t-m to p-t-p. 

The CRNC is responsible for the decision regarding having p-t-m transmission or no p-t-m transmission in a cell for a 
specific MBMS service. The CRNC informs all the SRNCs having UEs in that cell about its decision. The SRNC is the 
RNC controlling the RRC connection and RBs to a specific UE. In the example shown, the CRNC decided to no longer 
use p-t-m, then the SRNC decided to perform channel type switching to deliver the MBMS service over DTCH mapped 
on a dedicated channel. The RB SETUP message contains the MBMS Service Id. It is FES whether the SRNC always 
follows the CRNC's request or not. 

NOTE: the channel type switching in this case includes a change of both transport and logical channels. 

8.2.8 MBMS UE Uniting 



SRNC 



CN 



[RANAP] MBMS UE LINKING 
REQUEST 



[RANAP] MBMS UE LINKING 
RESPONSE 



Figure 8.2.8: MBMS UE linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to link a specific UE to one or several MBMS service contexts in the SRNC. The MBMS 
UE LINKING REQUEST message contains the whole hst of MBMS Service Ids and MBMS PTP RAB IDs (e.g. 
mapped from NSAPIs) activated by the UE. If there has not been an MBMS service context related to an MBMS 
Service Id then SRNC creates an MBMS service context as a result of this procedure. 
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8.2.9 MBMS UE De-Linking 



SRNC 



CN 



[RANAP] MBMS UE DE-LINKING 
REQUEST 



[RANAP] MBMS UE DE-LINKING 
RESPONSE 



Figure 8.2.9: MBMS UE De-linking signalling flow 

This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated MBMS Services. 

The signalling flow is used to remove a specific UE from one or several MBMS service context in the SRNC. The 
MBMS UE DE-UNKING REQUEST message contains the hst of MBMS Service Ids de-activated by the UE. 

8.2.10 MBMS Service Id Request 



UE 



RNC 



lu-cs connection establishment 



MSC 



RANAP]COMMON ID 



[RANAPJMBMS SERV CE ID REQ 



[RANAP] MBMS SERVIjCE ID RESPONSE 

< 



SGSN 



Figure 8.2.10: MBMS Service Id list over lu signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The list of MBMS 
services the user has joined is sent over lu. 

The purpose of this signalling flow is to perform UE linking for a RRC connected, PMM idle user. The UE provides 
an indication that the user has joined at least one MBMS service and the PS Domain specific IDNNS (the message that 
would carry this information is FES) whenever an lu-cs connection is established and the UE is PMM idle (that is there 
is no lu-ps connection), The RNC requests the MBMS services the UE has joined from the SGSN (or the SGSN the UE 
is attached to in case of lu-flex) using a connectionless procedure. The MBMS SERVICE ID REQ contains the IMSI 
of the UE. The SGSN response contains the full list of MBMS services the user has joined. 



The MBMS service hst is then stored in the RNC. 
context is removed in the RNC. 



The list is deleted when the UE moves to RRC idle and the RRC 
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8.2.1 1 MBMS Attach/Detach over lur 



CRNC 


[RNSAP] MBMS ATTACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS ATTACH 
RESPONSE 










w 





Figure 8.2.1 1-1 : MBMS attach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 

The purpose of this signalling flow is 

to either allow the CRNC to add one or several new UEs to the total number of UEs in a given cell using 
one or several MBMS services. The MBMS ATTACH REQUEST then contains the Cell Id of the new 
cell (may contain the URA Id of the new URA for UEs in URA_PCH state), the whole list of affected 
MBMS Service Ids and a UTRAN specific UE Identification if necessary. 

or to allow the SRNC to inform the DRNC in which URA notifications for MBMS Services have to be 
sent. The MBMS ATTACH REQUEST then contains a list of URAs and the corresponding MBMS 
Services. 



CRNC 


[RNSAP] MBMS DETACH 
REQUEST 


SRNC 




^ 








[RNSAP] MBMS DETACH 
RESPONSE 










w 





Figure 8.2.11-2: MBMS detach request signalling flow: Successful Operation. 

This signalling flow is only applicable for handling UEs in RRC connected mode with activated MBMS Services. 
The purpose of this signalling flow is 

- to either allow the CRNC to decrease the total number of UEs receiving one or several MBMS service in 
a given cell. The MBMS DETACH REQUEST contains the Cell Id of the old cell (may contain the URA 
Id of the old URA for UEs in URA_PCH state), the whole list of affected MBMS Service Ids and a 
UTRAN specific UE Identification if necessary. 

- or to allow the SRNC to inform the DRNC in which URA there is not anymore a need to send 
notifications for MBMS Services due to the presence of UEs in URA_PCH. The MBMS DETACH 
REQUEST then contains a list of URAs and the corresponding MBMS Services 

8.2.12 MBMS Channel Type Reconfiguration over lur 

These signalling flows need further study. 
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DRNC 




SRNC 




[RNSAP] MBMS CHANNEL TYPE 






RECONFIGURAITON INDICATION 






[RNSAP] MBMS CHANNEL TYPE 






RECONFIGURATION CONFIRMATION 















Figure 8.2.12: Channel Type Reconfiguration signalling flow: Successful Operation. 

This signalling flow is only applicable for handling MBMS UEs in RRC connected mode. 

The purpose of this signalling flow is that the CRNC informs the selected channel type to the SRNCs used in a cell 
under the CRNC. The MBMS CHANNEL TYPE RECONFIGURATION INDICATION contains a hst of U-RNTI, 
Channel type and MBMS Service Id corresponding to the UEs connected to the SRNC. 

8.2.13 Information Exchange over lur 

These signalling flows is used by the DRNC to acquire the MBMS related information for MBMS service identified by 
TMGI and is used between the RNCs, which are controlling cells neighbouring to each other for selective/soft 
combining in case of inter-RNC synchronization. 



DRNC/RNC1 



SRNC/RNC2 



[RNSAP] INFORMATION EXCHANGE 
INITIATION REQUEST 



[RNSAP] INFORMATION EXCHANGE 
INITIATION RESPONSE 



Transmission Mode Change 



[RNSAP] INFORMATION REPORT 



Figure 8.2.13: Information Exchange Initiation signalling flow: Successful Operation. 

The purpose of this signalling flow is that the DRNC request the APN and IP multicast address for an MBMS service. 
The INFORMATION EXCHANGE INITIATION REQUEST includes the TMGI for which the APN and IP multicast 
address are requested. In the INFORMATION EXCHANGE INITIATION RESPONSE message, the corresponding 
APN and IP multicast address are included. 

If the Information Exchange procedure is started and the transmission mode is changed, this shall be reported by the 
INFORMATION REPORT message. 

And the additional purpose of this signalling flow used in case of inter-RNC synchronization is 

to request the external neighbouring RNC(s) to provide the counting results in cells the neighbouring RNC 
controls 

to request the external neighbouring RNC(s) to inform about the transmission mode change in cells the 
neighbouring RNC controls for a MBMS session 
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to request the external neighbouring RNC(s) to provide the MBMS PTM RB configuration used in cells the 
neighbouring RNC controls 

to request the external neighbouring RNC(s) to provide the RLC Sequence Number. 

8.2.14 MBMS RAB Establishment Indication 



RNC 




CN 




[RANAP] MBMS RAB ESTABLISHMENT 
INDICATION 















Figure 8.2.14: MBMS RAB Establishment Indication procedure 



This signalling flow is used by the RNC to indicate to the CN the establishment of the MBMS RAB corresponding to 
the MBMS lu signalling connection. 

When the RNC decides not to establish an MBMS lu bearer, for a particular MBMS service, during MBMS Session 
Start procedure, for example the RNC does not control any contained in MBMS Service Area Information and the RNC 
does not belong to any of the RA in a list of RAs which lists each RA that contains at least one PMM-IDLE UE but 
later when a UE linking (via lu or lur) is performed or as a result (p-t-p decision) of channel type reconfiguration in 
another RNC, the RNC establishes the lu bearer and uses this procedure to inform the CN that an lu bearer has been 
established. 

If lu-Flex is active, the selection of the CN node is implementation dependant. 

The MBMS RAB ESTABLISHMENT INDICATION message contains the Transport Layer Address IE and the lu 
Transport Association IE. 



8.2.15 MBMS RAB Release 



RNC 


RANAP] MBMS RAB RELEASE 
REQUEST 


CN 




I 








[ 


RANAP] MBMS RAB RELEASE 

















Figure 8.2.15: MBMS RAB Release Request procedure. 

This signalling flow is used by the RNC to indicate to the CN to request the release of an MBMS RAB. 
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At reception of the MBMS RAB RELEASE REQUEST message the CN should initiate the release of all MEMS 
resources related to the lu connection without releasing the lu signalling connection. 

The RNC shall at reception of MBMS RAB RELEASE initiate the release of the related MBMS RAB resources. 

The MBMS RAB release may be initiated e.g. for the following reasons (unexhausted): 

There are lack of rafio resource in UTRAN and RNC decided to pre-empt an MBMS RAB for a on-going 
MBMS session based on Allocation/Retention Priority 

When there are no UEs with a given activated MBMS service consuming radio resources in cells under the RNC 
or the RNC is controlling UEs in cells under another RNC; 

In case of channel type switching from ptp to ptm in cells under control of another RNC in its role of DRNC; 

There are no cells under the RNC which are part of the RA List Of Idle UEs if received. 

8.2.1 6 MBMS Session Start procedure in case of IP Multicast transport 



RNC 



CN 



, [RANAP] MBMS SESSION START 



REQUEST 



IGMPJOIN 



[RANAP] MBMS SESSION START , 



RESPONSE 



Figure 8.2.16-1 : MBMS Session Start procedure. Successful operation. 

The MBMS Session Start procedure is initiated by the CN when an MBMS Session is started. The MBMS SESSION 
START REQUEST is sent to each RNC that is connected to the CN (in case of lu-flex the RNC may receive more than 
one MBMS SESSION START REQUEST message). 

The MBMS SESSION START REQUEST contains the MBMS Service Id, and optionally the MBMS Session ID, 
MBMS Bearer Service Type, the MBMS Session Attributes (MBMS Service Area Information, QoS parameters, . . .) 
and Transport Layer Address used for the IP-multicast and lu Transport Association (DL TEID) IE. In addition in case 
PDCP is used for the MBMS service the PDCP information is included. It may also include a list of RAs which lists 
each RA that contains at least one PMM-IDLE UE that has activated the service. 

The RNC stores the session attributes in the MBMS Service Context, sets the state attribute of its MBMS Service 
Context to 'Active' and joins the IP Multicast group, which is used for the User data delivery of this MBMS session 
between the GGSN and RNCs in case radio resource is available. In case of successful joining the indicated IP 
Multicast group the RNC replies to the CN nodes from which it has received the MBMS Session Start Request message 
that the IP Multicast Bearer setup was successful and establishes the radio resource for the transfer of MBMS data to 
the interested UEs. 
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8.2.17 MBSFN MCCH Information 



CRNC MRNC 

MBSFN MCCH INFORMATION 



Figure 8.2.17-1: MBSFN MCCH Information procedure, Successful Operation 

The signalling flow shall be used only if MRNC is used for MBSFN operation. 

The MBSFN MCCH INFORMATION message contains the MCCH messages list sent on the MRNC and the MCCH 
configuration information of the MRNC. 

The signalling flow is used by the MRNC to inform the CRNC of the MCCH configuration and scheduling information 
used in MRNC upon receipt of MBMS SESSION START message from CN. 

The CRNC shall prepare the setup of the requested MBMS sessions upon receipt of MBMS SESSION START message 
from CNDthen instead of preparing RRC messages and physical configuration, wait for the MBSFN MCCH 
INFORMATION message that is sent from MRNC. 

Upon receipt of the MBSFN MCCH INFORMATION message, if the MCCH Configuration IE exists, the CRNC shall 
setup or reconfigure the MCCH of all cells in the MBSFN cluster with the configuration contained in this IE, and 
update the System Information of these cells. 

The CRNC shall decode the L3 Information IE contained in the MCCH Message List IE and apply the RLC/MAC/PHY 
configuration specified by relative MCCH Message to setup the RB information of MTCH, and then send the L3 
Information IE on the MCCH in the receiving sequence at the beginning of the first MCCH modification period 
following the CFN carried in the message. 



8.3 MBMS Uu Signalling Flows 

8.3.1 Broadcast of IVIBIVIS System Information 



UE 



CRNC 



MBMS SYSTEM INFORMATION 



Figure 8.3.1 : Broadcast of MBMS system information. 

This signalhng flow is applicable for handUng MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for UTRAN to broadcast MBMS system information to UEs using the BCCH. The 
MBMS SYSTEM INFORMATION shall be repeatedly transmitted after its first transmission. Upon receiving the first 
MBMS SYSTEM INFORMATION, the UE shall establish the radio bearer carrying an MCCH. 

The MBMS SYSTEM INFORMATION includes: 

- MCCH schedule information (access info, repetition and modification periods) 
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- Configuration of a radio bearer carrying an MCCH 
More information may be included in the MBMS SYSTEM INFORMATION. 

8.3.2 MBMS Service Information 



UE 



CRNC 



MBMS SERVICE INFORMATION 



Figure 8.3.2: MBMS service information signalling flow 

This signalhng flow is applicable for handhng MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for RNC to inform UEs of all of MBMS services available in one cell. The 
MBMS SERVICE INFORMATION shall be transmitted periodically on MCCH to provide an indication of the status of 
the MBMS service in the cell and to support mobility. 

The MBMS SERVICE INFORMATION contains MBMS service ids, optionally the MBMS Session ID, and an 
indication of the service status in the cell i.e. whether it is provided by p-t-m or p-t-p bearers or whether explicit release 
is indicated. The MBMS service ids indicate the MBMS services which are being served in the cell or the MBMS 
services which can be served if the UE requests it. P-t-m indication indicates that the MBMS service is on p-t-m in the 
cell, thus it informs the UE of the need of reception of the MBMS RADIO BEARER INFORMATION. 

8.3.3 MBMS Radio Bearer Information 



UE 


MBMS RADIO BEARER 
INFORMATION 


CRNC 




^ 








^ 









Figure 8.3.3: MBMS radio bearer information signalling flow 

This signalhng flow is apphcable for handhng MBMS to UEs in IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is for the RNC to inform UE(s) regarding the MTCH radio bearer information. 
MBMS RADIO BEARER INFORMATION is only available for p-t-m transmission. MBMS RADIO BEARER 
INFORMATION shall be transmitted periodically on MCCH to support mobility in the MBMS service. 

MBMS RADIO BEARER INFORMATION includes MBMS Service Id, radio bearer, transport channel and physical 
channel information per MBMS service. 
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8.3.4 MBMS Access Information 



UE 



CRNC 



MBMS ACCESS INFORMATION 



Figure 8.3.4: MBMS Access Information signalling flow 

This signalling flow is applicable for handling MBMS UEs in IDLE mode or URA_PCH, CELL_PCH, CELL_FACH 
state. 

The purpose of the signalling flow is for the RNC to inform UE(s) with particular activated MBMS service of the 
potential need to make an MBMS Counting Response i.e. establish an RRC connection or make a cell update. The 
MBMS ACCESS INFORMATION is transmitted during counting and re-counting on MCCH. The MBMS ACCESS 
INFORMATION includes, for each service for which counting is required, the MBMS service identifier, probability 
factors for idle and connected modes and an indication of the connected mode states to which the signalling flow 
applies. 

8.3.5 MBMS Neighbouring Cell Information 



UE 


/IBMS NEIGHBOURING CELL 
INFORMATION 


CRNC 












^ 









Figure 8.3.5: MBMS Neighbouring Cell Information signalling flow 

This signalhng flow is apphcable for handhng MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the MBMS NEIGHBOURING CELL INFORMATION signalhng flow is for the UTRAN to inform to 
UEs of the MTCH configuration of the neighbouring cells which are available for selective combining. In case of partial 
soft combining, the MBMS NEIGBOURING CELL INFORMATION contains the LI -combining schedule, which 
indicates when the soft combining is applicable between the specific S-CCPCH of the cell and the specific S-CCPCH of 
the neighbouring cell. With MBMS NEIGHBOURING CELL INFORMATION the UE is able to receive MTCH 
transmission from neighbouring cell without reception of the MCCH of that cell. The MBMS NEIGHBOURING CELL 
INFORMATION shall be repeatedly transmitted on MCCH when selective or soft combining is utilized in the MBMS 
p-t-m transmission in the given cell group. 
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8.3.6 MBMS Joined Indication 



UE 



SRNC 



MBMS JOINED INDICATION 



Figure 8.3.6: MBMS joined indication signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The MBMS 
JOINED INDICATION is sent over the DCCH. 

The signalling flow is initiated by the UE after entering RRC-Connected, PMM-IDLE state. The purpose of the signalling flow 
is to enable the UE to inform the SRNC that the user has joined at least one MBMS service. The SRNC requests the MBMS 
services the UE has joined from the SGSN as defined in subclause 8.2.10. 

In SRNC relocation this information is transmitted from source RNC to target RNC. 

NOTE: If SRNC has valid linking information the complete service list of activated services is also transmitted 
from source RNC to target RNC in SRNC relocation. 

8.3.7 MTCH Scineduling Information 



UE 


MTCH SCHEDULING 
INFORMATION 


CRNC 




^ 

















Figure 8.3.7: MTCH scheduling information. 

This signalhng flow is apphcable for handling MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the signalling flow is to enable UEs to perform discontinuous reception of MTCH. The UE may 
discontinuously receive MTCH based on scheduling information indicated by the MTCH SCHEDULING 
INFORMATION. This signalhng is transmitted on MSCH mapped on SCCPCH carrying MTCH. The MTCH 
SCHEDULING INFORMATION is signalled on each MSCH repetition period. The MSCH repetition period and the 
offset from the cell timing are indicated on MCCH. In case of soft combining, the MSCH repetition period is same for 
all soft combinable S-CCPCH. The scheduling information allows to cover different periods for different MBMS 
services. 

The MTCH SCHEDULING INFORMATION includes for each service: 

- MBMS service Id (the actual coding is defined in stage-3). 

- Beginning and duration of MBMS data transmission (one contiguous block or more is defined in Stage-3). 

- Duration can be infinite (no DTX). This option could be signalled in the MCCH (Stage-3 definition). 

-Indication of no MBMS data transmission for either this period or several consecutive periods (a period is expressed in 
MSCH repetition period). 
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8.3.8 MBMS Change Information 



UE 


MBMS CHANGE 
INFORMATION 


CRNC 




^ 








^ 









Figure 8.3.8: MBMS change information. 

This signalling flow is applicable for handling MBMS to UEs in PMM IDLE and CONNECTED mode. UTRAN 
should transmit this signalling flow in beginning of each modification period on MCCH and repeat it at least in every 
repetition period of that modification period. UE shall read this information flow when detecting that MICH bits set for 
a service that UE has activated, or periodically at the begin of each modification period when receiving MTCH. 

The purpose of the signalling flow is to indicate MBMS services whose MCCH information is changed in that 
modification period. The content of MBMS CHANGE INFORMATIO shall be minimized, so that the MCCH reading 
time for the UEs, activated MBMS service whose MCCH information is not modified on that modification period, is 
minimized. 

The MBMS CHANGE INFORMATION includes: 

The MBMS service Ids for which MCCH information is modified on that modification period. 



8.3.9 MBMS P-T-P Modification Request 



UE 


MBMS P-T-P 
Modification Request 


SRNC 
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w 





Figure 8.3.9: MBMS P-T-P Modification Request. 

This signalling flow is applicable for handling UEs with an activated service that requires MBMS p-t-p RB in PMM 
IDLE and CONNECTED mode. In idle mode, URA_PCH and CELL_PCH states the UE may transmit this signalling 
flow to request the setup of a p-t-p MBMS RB after receiving the indication on MCCH that p-t-p transfer mode is 
utilised or, in CELL_DCH state, to request the release of the p-t-p MBMS RB due to higher priority MBMS service, or 
to indicate the frequency used for transmitting the higher priority service as specified in subclause 5.2.8. This signalling 
flow is transmitted on DCCH or on CCCH dependent upon UE state. 

UEs in idle mode are required to perform RRC connection establishment for sending this information flow. UEs that are 
in URA_PCH or CELL_PCH state are required to make a cell update and UEs that are in CELL_DCH state transmit an 
MBMS MODIFICATION REQUEST message. 

When UTRAN receives this message from the UE, the UTRAN may setup or release the p-t-p MBMS RB by normal 
RB release procedure or , in the case of a preferred frequency being indicated, it may perform inter-frequency HHO. 

The MBMS P-T-P Modification Request message includes the identity of the MBMS service when the service appears 
in the list of MBMS Selected Services. 
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8.3.10 MBMS Counting Response 



UE 



CRNC 



MBMS Counting Response 



Figure 8.3.10: MBMS Counting Response. 

This signalling flow is applicable for UEs passing the probability check in counting procedure in idle mode or 
URA_PCH, CELL_PCH or CELL_FACH state. For the UE in idle mode this signalling flow refers to the complete 
RRC connection establishment procedure. For UEs in URA_PCH, CELL_PCH and CELL_FACH state this signalling 
flow refers to cell update procedure. 

The MBMS Counting Response message includes the identity of the MBMS service when the service appears in the list 
of MBMS Selected Services. 

8.3.1 1 MBMS Selected Services Information 



UE 


MBMS Selected Services 
Information 


CRNC/ 
SRNC 





















Figure 8.3.1 1 : MBMS Selected Services Information. 

This signalling flow is applicable for UEs entering CELL_DCH state. The purpose of the signalling flow is to enable 
the UE to inform the SRNC that the user requires the reception of MBMS Selected Services. When the SRNC is not the 
CRNC of the UE, this signalling flow may interact with the URA linking/de -linking described in subclause 5.1.10. 

This signalling flow is also applicable for UEs in CELL_DCH states, when the list of MBMS Selected Services has 
been modified. 

This signalling flow is also apphcable for UEs in CELL_PCH, URA_PCH and CELL_FACH states when the hst of 
MBMS Selected Services has been modified by the upper layers and the MBMS Service appears in the MCCH of the 
cell and the RNC has indicated in the MBMS GENERAL INFORMATION message that it should be notified of a 
change to this list. If an MBMS Service is contained in the list of MBMS Selected Services but is currently not 
available in the cell, when the service appears on the MCCH the UE does not perform this signalling flow. 

The purpose of the signalling flow is to enable the UE to inform the CRNC that the list of MBMS Selected Services in 
the UE has been modified. 



Security for MBMS 



Ciphering for MBMS multicast data is done between the BM-SC and the UE as defined in [7]. Therefore, for MBMS p- 
t-m data transmissions no radio interface ciphering is applied. 

In case of p-t-p MBMS data transmissions, if the security is activated for the UE the ciphering is also applied for p-t-p 
MBMS data RB as for any other RB of the UE. 
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1 Mobility Procedures for IVIBIVIS 

One of the requirements in [5] is: "Data loss during cell change should be minimal". Therefore, when the UE receiving 
an MBMS session in idle mode or connected mode (not including CELL_DCH) re-selects between cells, it should be 
possible to provide service continuity to this UE. 

The following mechanism has been identified to minimise the data loss on cell change. 

1 0.1 Use of Periodical Transmission of MBMS Critical 
Information 

In this mechanism, the cell periodically transmits an MBMS critical information, informing all MBMS services 
currently configured for p-t-m transmission or p-t-p transmission. If MBMS service is configured for p-t-m 
transmission, the periodical transmission of MBMS critical information may also contain the Radio Bearer information 
corresponding to each MBMS service and Neighbouring cell information. 

If the cell is configured for p-t-p transmission, then the UE would perform a normal RRC connection establishment. 

1 0.2 UE Actions for Mobility 

The UE mobility between intra frequency cells is not affected by the MBMS reception. The mobility between different 
frequency layers is affected by the Frequency Layer Convergence process as defined in 1 1 .2, if used by the network. 

In CELL_FACH and in CELL_DCH state the RRC operation has priority over MBMS reception, thus UE performs the 
inter frequency and inter RAT measurements as configured by the SRNC. UTRAN should utilize different periodicities 
between MCCH transmissions and CELL_FACH state measurement occasion, such that CELL_FACH state 
measurements and MCCH transmissions are not constantly overlapping for some UE. 

In Idle mode and in CELL_PCH, URA_PCH states the measurements are performed as configured by the network 
based on the Release 5. The MBMS specific measurement occasions to S-CCPCH for UEs in idle mode and in 
CELL_PCH, URA_PCH states are not introduced and measurements have priority over MBMS reception. The usage of 
channel protection (channel coding) to recover some of the lost transport blocks is possible. 

UEs may have DRx occasions for specific MBMS service when UE can stop decoding S-CCPCH and perform 
measurements. DRx occasion are based on scheduling information. 

R'99 standards have some means to reduce need for number of measurements, which can be utilized for MBMS. 

When the UE reselects the cell due to the mobility or returns to on service from out of service, the UE shall acquire the 
MCCH information if the activated MBMS service is available in the selected cell for the reception of the service. The 
service is available when the session has been already started and the service is being served on p-t-p/p-t-m in the cell, 
or the service can be served in the cell if the UE requests it. 

If the MBMS service is available in the cell, the UE will perform an action for the service reception in the cell. For 
example, if the service is on p-t-p, the idle mode UE will initiate RRC connection establishment procedure. Otherwise, 
the UE does not need to perform such an action in the cell. The UE, which moves to the new cell, will operate 
according to the RRC state/mode as follows. 

Whenever the UE moves between p-t-m cells while continuing to receive a service, UE shall receive MCCH 
information in a new cell, which includes an MBMS cell group identity. If a UE moves between cells belong to the 
same MBMS cell group based on the MCCH information, the UE does not need to re- establish RLC entity and re- 
initialise PDCP entity for the service received on MTCH. If a UE moves between cells belong to different MBMS cell 
groups based on the MCCH information, the UE shall re- establish RLC entity and re- initialise PDCP entity for the 
service received on MTCH. 

10.2.1 RRC idle mode 

Idle mode UE shall: 

if BCCH contains information regarding the MCCH in the new cell: 
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- listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if the MBMS SERVICE INFORMATION contains the activated MBMS service-id: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

initiate RRC connection establishment procedure and request the setup of MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the activated MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.2 URA_PCH State 

URA_PCH state UE shall: 

perform URA update procedure if needed; 

if BCCH contains information regarding the MCCH in the new cell: 

- hsten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the activated MBMS service id: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else: 

initiate cell update procedure and request to setup the MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before MBMS SERVICE 
INFORMATION message and; 

- if MBMS RADIO BEARER INFORMATION contains the activated MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.3 CELL_PCH 

CELL_PCH state UE shall: 

perform cell update procedure; 

if BCCH contains information regarding the MCCH in the new cell: 

- hsten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the activated MBMS service id and: 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION message and listen to the MTCH. 
else: 

initiate the cell update procedure and request to setup the MBMS p-t-p RB. 
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- if the UE receive the MBMS RADIO BEARER INFORMATION before the MEMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the activated MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.4 CELL_FACH 

CELL_FACH state UE shall; 

perform cell update procedure 

if BCCH contains information regarding the MCCH in the new cell: 

- hsten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the activated MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 
else; 

initiate request to setup the MBMS p-t-p RB; 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the activated MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.5 CELL_DCH State 

CELL_DCH state UE shall: 

act on the RRC message received on DCCH in handover, 
if the UE has the capability to support MBMS in CELL_DCH: 

if BCCH contains information regarding the MCCH in the new cell: 

- hsten to the MCCH and receive the MBMS SERVICE INFORMATION; 

- if MBMS SERVICE INFORMATION contains the activated MBMS service id and; 

- if MBMS SERVICE INFORMATION indicates that the service is on p-t-m: 

- receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH. 

- if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION and; 

- if MBMS RADIO BEARER INFORMATION contains the activated MBMS service id: 

- hsten to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 
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1 1 Resource Management for MBMS 
11.1 MBMS Access Control Procedure 

MCCH messages initiating counting or recounting cause multiple responses from UEs within a cell. This may result in 
RACH congestion if number of UEs is high in a cell. To avoid this, CRNC may perform MBMS access control 
procedure during counting or recounting procedure. MBMS access control procedure is described in Figure 11.1. 
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Figure 11.1: MBMS Access Control Procedure 

1 . CRNC calculates an initial probability factor for an MBMS service when a MCCH message causing counting or 
recounting is about to be sent. CRNC can use different probability factor for UEs in Idle mode and for different 
UEs in URA_PCH, CELL_PCH and CELL_FACH. 

2. CRNC includes the probability factor into the MCCH message and sends it to UEs. This can be done in MBMS 
Group Notification. 

3. UEs in idle mode or in URA_PCH, CELL_PCH and CELL_FACH state passing the probability check performs 
counting response UEs keep listening to MCCH to get updated probability factor until they have successfully 
responded to counting or counting is no longer required. 

4. CRNC detects the probability factor needs to be updated. Detecting mechanism is not to be standardized. 

5. CRNC recalculates the probability factor. The way of calculating new probability factor is not to be 
standardized. 

6. CRNC includes the updated probability factor into the MCCH message and sends it to UEs. 
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7. UEs in idle mode or in URA_PCH, CELL_PCH or CELL_FACH state that pass the probabihty check, by using 
updated probabihty factor, perform counting response. 

CRNC and UEs that are stiU trying to perform the counting response repeat step 3 ~ step 7 until e.g. counting or 
recounting procedure ends. 



1 1 .2 Frequency layer Convergence 



Frequency Layer Convergence (PLC) denotes the process where the UTRAN requests UEs to preferentially re-select to 
the frequency layer on which the MBMS service is intended to be transmitted. This layer preference could be done by 
an additional MBMS session related Layer Convergence Information (LCI) such as offset and target frequency. The 
PLC is supported by specifications for both networks utilizing HCS and for networks not utilizing HCS. 

The preferred layer (PL) is indicated per MBMS service and the LCI (offset) is the same for all MBMS services on a 
given preferred layer. UTRAN can consist of multiple preferred layers and the PL for given services is decided by 
RRM. Thus the PL for an MBMS service might be different in different parts of the service area. Network co-ordination 
between RNCs may be added for the Rel-7. The CN may also request the RNC (e.g. using 'no-PLC-flag' value) not to 
apply any frequency layer convergence mechanisms for the MBMS service (e.g. emergency service). In case no PL info 
is specified for the MBMS service, the UE may assume that the MBMS service is available on all frequencies. 

The LCI can be signalled to UEs by the CRNC after the session start is received over lu interface until reception of the 
session stop. The UEs shall take LCI into account whenever it is signalled on the MCCH in Idle mode and URA_PCH, 
CELL_PCH and in CELL_PACH states. The PLC is not applicable in CELL_DCH state, as it is only effecting UEs cell 
re-selection procedure. 

The UE shall ignore Sintersearch parameter only for the potential preferred layers when LCI is signalled and on 
preferred layer the UE shall apply the Sintersearch parameter. In case of UE is in CELL_PACH state without 
measurement occasions, the UE may not be able to measure cells on preferred layers. 

In the case that the UE has joined multiple services and they have different frequencies as preferred layer, the UE 
should apply the PLC applicable for the highest priority MBMS service, which it has activated and has a PL. The 
priority setting of different MBMS services is decided by NAS. 

Based on RRM decision, a given MBMS service can be provided on non-preferred layer by p-t-p or p-t-m transfer 
mode. 

The details of the mechanism are defined in state 3. 



1 1 .3 Frequency layer Dispersion 



Frequency Layer Dispersion (PLD) denotes the process where the UTRAN redistributes UEs across the frequencies. 
UTRAN can use PLD per MBMS session. 

For FDD, the PLD is applicable in Idle mode, URA_PCH, CELL_PCH and CELL_PACH states. 

For TDD, the PLD is apphcable in Idle mode, URA_PCH and CELL_PCH states. 

When PLC is applied, the UE stores the frequency where it was camped previously. Upon session stop or service 
deactivation, the UE attempts to return to that frequency. 

If the UE does not find a suitable cell on the target frequency, the UE attempts to select a cell on a randomly chosen 
frequency. 

Dispersion applies when the MBMS session on the MBMS preferred frequency ends, or when the MBMS service on the 
MBMS preferred frequency is deactivated by the UE. Dispersion does not apply in the case where the UE decides to 
receive another service for which PLC is applied. 

The details of the mechanism are defined in the stage 3. 
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Annex A (informative): 
MBIVIS Phases in UTRAN 



time 




MBMS phasp 
in UTRAN 1 



Figure A: Timeline of lUIBMS Service 

The UTRAN MBMS behavior is divided into 3 phases. Figure A illustrates the timeline of an MBMS service with 
regards to these phases. 



A1 Security for IVIBIVIS 



A cell stays in phase 1, if there is no ongoing session for the MBMS service, or if it does not belong to the MBMS 
service area of the service. 

A UE that has joined an MBMS service may regularly try to receive MBMS notification in a cell [FFS]. At this phase 
the UE does not request service delivery to UTRAN. 



A2 MBMS Phase 2 



This phase starts when UTRAN receives the MBMS "session start" from CN, and ends when UTRAN initially sets up 
MBMS radio bearer for the session, or decides not to set up the MBMS radio bearer in a cell. 
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In this phase, UTRAN transmits notification to UEs about the incoming service and could perform counting procedure 
to decide the type of MBMS radio bearer. UTRAN decides whether to set up p-t-m, p-t-p radio bearer or no radio 
bearer, based on the number of UEs that expected to receive the service in the cell. A UE that has at least one activated 
MBMS service acts on an RRC message in MCCH. 



A3 MBMS Phase 3 



This phase starts after initial MBMS radio bearer setup and ends when UTRAN receives the MBMS "session stop" 
from CN. 

In this phase, UTRAN transmits the data for the MBMS service received from CN using, if any, the established radio 
bearer. If there is no set-up radio bearer, UTRAN waits for service delivery request from UE. Recounting and radio 
bearer reconfiguration may be performed during this phase. 

UTRAN behaviour in this phase can be divided into three states: no transmission, p-t-p transmission, and p-t-m 
transmission. Each cell belonging to the same MBMS service area may be in any of three states. With the variation of 
the number of UEs, the state of a cell may change between the three states. UTRAN may broadcast the state of each 
cell. 

1 ) No Transmission: In this state of a cell, there is no established radio bearer because there is no UE who wants 
to receive the service. An MBMS-joined (or MBMS-interested in broadcast mode) UE in idle mode that moves 
into the cell of this state requests service delivery to UTRAN. 

2) P-t-p Transmission : In this state of a cell, p-t-p radio bearer is established. A UE that has joined (or interested 
in broadcast mode) an MBMS service may receive MBMS data over p-t-p radio bearer if there is MBMS data to 
receive. 

3) P-t-m Transmission: In this state of a cell, p-t-m radio bearer is established. A UE that has joined (or interested 
in broadcast mode) an MBMS service may receive MBMS data over p-t-m radio bearer if there is MBMS data to 
receive. 



A4 MBMS Phases and Status Parameters 

Table 1 lists the MBMS parameters that need to be broadcast in each MBMS phase. The list is [FES] 

Table 1 : MBMS Status Parameters 





Phase 1 


Phase 2 


Phase 3 


Description 


Service ID 


X 


O 


O 


Identity of the Service 


Transmission 
State 


X 


X 


O (NONE/p-t-p/p-t-m) 


State of the cell for MBMS 
transmission 


Counting 


X 


O (On/Off) 


O (On/Off) 


Whether counting procedure is 
going on. 



1 ) Service ID: This parameters indicates is the identity of the service concerned. 

2) Transmission state: This parameter indicates to UE(s) the state of the concerned cell while it is in phase 3. 
According to this parameter, UE entering the cell starts re-configuration of the radio bearer, or requests service 
delivery to UTRAN. Specifically, if this parameter is set to "p-t-m", UE receives service over p-t-m radio bearer 
and if set to "p-t-p", UE receives service over p-t-p radio bearer. If it is set to NONE, UE has to request UTRAN 
to deliver the service. 

3) Counting : Tine counting parameter informs UEs whether counting is required (and is going on) or not. If this 
parameter is set to "ON", UE should perform RRC connection procedure. 
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Annex B (informative): 
MBIVIS Control Information 

Tables 2 and 3 describe MBMS control information in the downlink and uplink. 

Table 2: Mapping of MBMS Control Parameters in DL 



Information Element 


Description 


MICH - Transmitted continuously - Can be modified at a modification period boundary 


MBMS Notification 
Indicators 


Indicates when new information is to be transmitted on MCCH in the next modification period. 


BCCH - Transmitted periodically 


MCCH System 
Information 


Includes: 

- Configuration of the radio bearer carrying MCCH, 

- MCCH schedule information (access info, repetition and modification periods). 


MCCH - Non Critical Information - Transmitted at access info events - Can be modified at any transmission 


MBMS Access 
Information 


Contains parameters that control, for the purposes of counting, whether UEs should establish an 
RRC connection (idle mode) or make a cell update (URA_PCH state). It may include for each 
service for which counting is in progress; 

- MBMS service identity, 

- Probability factor (Idle mode), 

- Probability factor (URA_PCH), 

Additional parameters may be identified in stage 3. 


MCCH - Critical Information - Transmitted at repetition period Events - Can be modified at a modification 
period boundary 


MBMS Change 
Information 


Identifies MBMS services for which parameters are modified in this modification period. It 
may include for each service listed: 

- MBMS service identity, 

- MBMS session identity. 

Additional parameters may be identified in stage 3. In stage 3, MBMS Change Information is 
contained in the MBMS MODIFIED SERVICES INFORMATION message. 


MBMS Service 
Information 


Identifies MBMS services that are available in the cell. It may include for each service listed: 

- MBMS service identity, 

- MBMS session identity, 

- Indication that a p-t-m bearer is established for the service in the cell, 

- RB release indication, 

- Preferred frequency layer information. 

Additional parameters may be identified in stage 3. In stage 3, MBMS Services Information for 
a service is contained in either the MBMS MODIFIED SERVICES INFORMATION or the 
MBMS UNMODIFIED SERVICES INFORMATION messages depending upon the change 
status of the service. 


MBMS Radio Bearer 
Information 


Contains, for one or more MBMS services information describing the radio bearer and the p-t-m 
bearer that is used within the serving cell. It may include for each service listed: 

- MBMS service identity, 

- MBMS cell group identity, 

- Physical channel information, 

- Transport channel information, 

- Radio Bearer information. 

Additional parameters may be identified in stage 3. 
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MBMS Neighbouring 
Cell Information 


Contains, for one or more MBMS services transmitted in neighbour cells that can be used for 
soft or selective combining, information describing the p-t-m bearer to which it is mapped in the 
neighbour cell. It may include for each service listed; 

- MBMS service identity, 

- Cell identification information, 

- Physical channel information, 

- Transport channel information, 

- Radio Bearer information, 

- LI scheduling information, 

- Soft/ selective combining information. 
Additional parameters may be identified in stage 3. 


MSCH - Transmitted periodically 


MTCH Scheduling 
Information 


Contains information that enables UEs to perform discontinuous reception of MTCH. It may 
include for each of one or more services: 

- MBMS service identity, 

- The start time and duration of a period of data transmission, 

- Indication that there is no data transmission for one or more MSCH repetition periods. 



Table 3: Mapping of MBMS Control Parameters in UL 



Information Element 


Description 


DCCH - Service Related Control Information 


MBMS Joined Indication 


Indicates that a PMM IDLE state UE in RRC connected mode has joined at least one 
MBMS service 


MBMS P-T-P 
Modification Request 


UEs in CELL_DCH state may transmit this signalling flow to request the release of a p-t-p 
MBMS RB for a higher priority MBMS service. 
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0045 


- 


Introduction of MBMS Improved Solution 


8.1.0 


8.2.0 




RP-42 


RP-081129 


0046 


2 


Support for 3.84 Mcps MBSFN 1MB operation 


8.1.0 


8.2.0 


03/2009 


RP-43 


RP-090143 


0047 


- 


Correction of MBMS improvements 


8.2.0 


8.3.0 




RP-43 


RP-090264 


0048 


- 


Correction on MBMS Improved Solution 


8.2.0 


8.3.0 


12/2009 


RP-46 


RP-091326 


0049 


- 


Correction for the Synchronisation Sequence 


8.3.0 


8.4.0 


12/2009 


RP-46 






- 


Upgrade to the Release 9 - no technical change 


8.4.0 


9.0.0 


03/2010 


RP-47 


RP-1 00305 


0051 


- 


Clarification on Total counter frame 


9.0.0 


9.1.0 




RP-47 


RP-1 00305 


0052 


- 


Calculation of time stamp value 


9.0.0 


9.1.0 




RP-47 


RP-1 00291 


0053 


- 


Update for SYNC Deschption 


9.0.0 


9.1.0 
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